⎕NPARTS

[Phil Last]

This is not a bug report.
Dyalog appears to deal differently to Windows with files named merely as '.ext'. Windows explorer will name this as an "EXT file" and suppress its display if one turns off display "File name extensions" whereas ⎕nparts gives it an empty extension with ".ext" as the name.

      ]disp ⎕nparts '\Demo\.test'
┌→─────┬─────┬─┐
│\Demo\│.test│ │
└─────→┴────→┴⊖┘

Anything preceding the dot forces the Windows conforming behaviour

      ]disp ⎕nparts '\Demo\this.test'
┌→─────┬────┬─────┐
│\Demo\│this│.test│
└─────→┴───→┴────→┘

including a blank

      ]disp ⎕nparts '\Demo\ .test'
┌→─────┬─┬─────┐
│\Demo\│ │.test│
└─────→┴→┴────→┘

or just another dot.

      ]disp ⎕nparts '\Demo\..test'
┌→─────┬─┬─────┐
│\Demo\│.│.test│
└─────→┴→┴────→┘

I have no problem with this and can work with it apart from the possibility that it might be changed at some time in the future. I'm not assuming Microsoft will follow Dyalog any too soon but if Dyalog decide to move I should like it to be sooner rather than later if at all.

[Richard|Dyalog]

Phil, this is the intended behaviour, and we do not expect to change it. Let me explain why.

One important aspect of the new portable file functions is that they behave, as far as possible, in the same way on all platforms. ⎕NPARTS is following a UNIX-like behaviour here for several good reasons. On linux, for example, you get will see the following:

* File names beginning with a dot are common because they are implicitly "hidden". The file ".profile", for example, exists in many linux home directories; this is not a name you would consider to be an empty basename and extension ".profile" but a file with a basename ".profile" and no extension.
* gcc (the compiler) infers the type of its source file from the extension, so "util.c" is understood to contain C code. gcc does *not* infer that the file ".c" contains C code; it interprets this name, as ⎕NPARTS does, as a file with a basename ".c" and no extension. (this is likely derived from the fact that typically the file "util.c" ultimately created the executable file named "util", and the name "" would be invalid).

On Windows, however, such names are very unusual and, indeed, Microsoft doesn't really support them. As you have shown, Explorer seems happy if it encounters a name with a zero-length basename but really this is a facade. Try renaming an existing file in Explorer so that it begins with a '.', for example, and it will tell you that is invalid. Similarly, if you save a Word document as ".docx" and try to reload it from the File->Open menu you will told that the name is invalid (and worse, even though Explorer will show this as a Word file, you will crash Word if you open it by clicking on it from there).

So, ⎕NPARTS behaves as expected on UNIX-like platforms, and on Windows there's not really any expected behaviour but at least the way it works helps prevent you deriving a name with no basename which, as can be seen, is something you really don't want to do.

[Phil Last]

A different aspect of this. Still a part of my tentative drive towards interoperability.

In windows it doesn't usually matter whether a final '\' or '/' is present in specifying a directory and ⎕MKDIR doesn't seem to mind, which hints to me that the 'nixes don't either.

      '/alpha/bravo/charlie' ←→ '/alpha/bravo/charlie/'

But ⎕NPARTS seems to mind rather a lot and gives totally different results.

      ⎕NPARTS '/alpha/bravo/charlie'
('/alpha/bravo/' 'charlie' '' )
      ⎕NPARTS '/alpha/bravo/charlie/'
('/alpha/bravo/charlie/' '' '' )

I've found a workaround, without having to insert lines of code testing whether I've got a trailing slash or not and conditionally dropping it, by supplying the '1' left argument and suffixing either '/' or '/.' depending upon which of the two different results above that I want, meaning I can accept either form, with or without, as input.

The trouble is I'm guessing that '/.' may not be understood or rather may be understood rather differently in 'nix.

Is there a reason for the difference?

[Richard|Dyalog]

Phil - you are right in that some Windows commands don't distinguish between there being a trailing slash or not, but others do. The difference is principally between commands that expect a directory and those that expect a filename / a filename or a directory.

For example, at a command prompt try:

notepad %TEMP%\x (it offers to create x.txt if it does not exist, and then edits it)
notepad %TEMP%\x\ (it complains that the directory does not exist)

With copy it's impossible to tell what it will do without looking at the file system. For example:

echo x > %TEMP%\x
mkdir %TEMP%\y

copy %TEMP%\x %TEMP%\x (it objects to overwriting the file x)
copy %TEMP%\x %TEMP%\y (it copies x into the directory z)
copy %TEMP%\x %TEMP%\z (it copies x as y)

copy %TEMP%\x %TEMP%\x\ (it says that the directory doesn't exist)
copy %TEMP%\x %TEMP%\y\ (it copies x into the directory z)
copy %TEMP%\x %TEMP%\z\ (it says that the directory doesn't exist)

Try also putting a slash at the end of the name you specify when saving a Word document and it will complain it is an invalid filename.

So, whether there is a difference or not really depends on which bit of Windows you look at.