3 ms·

How is PowerShell (+ NTFS) in this regard? Does it's object oriented/structured data paradigm fare better? Edit: and now that PowerShell is actually available

How is PowerShell (+ NTFS) in this regard? Does it's object oriented/structured data paradigm fare better? Edit: and now that PowerShell is actually available on Linux, how does it fare there as well?

tyingq 8y ago
It has different issues. Try creating a file called aux, for example. Or even aux.js: https://github.com/gajus/react-aux/issues/10 https://github.com/gajus/react-aux/issues/10 See: https://docs.microsoft.com/en-us/windows/desktop/fileio/naming-a-file https://docs.microsoft.com/en-us/windows/desktop/fileio/nami...
- Arnavion 8y ago
  >It has different issues. To clarify the "it" here, NTFS allows you to create a file named `aux.js` just fine. The thing that injects special handling of `aux.js` is the Windows object layer that sits on top of it. CreateFileW(LR"#(\\?\C:\Users\Arnavion\Desktop\aux.js)#", GENERIC_WRITE, 0, nullptr, CREATE_NEW, 0, nullptr) will create a file named `aux.js` just fine, since it tells the Windows layer to not normalize names, which includes disabling the special handling of files named `aux`.
  - tyingq 8y ago
    The main thread is discussing, for example, Unix filenames with newlines, which can similarly be created with ease, but cause problems later with other tools.
Arnavion 8y ago
NTFS is not too different from Linux filesystems. It allows any characters except `\` and `\0` in path components (explorer blocks a few more but that can be bypassed using namespaced paths). As for PS, commandlets with parameters do not have a problem with filenames being mistaken for parameters. Eg `gc $foo` will never parse the contents of `$foo` as a parameter name and always as the value of the (implicit) `-Path` parameter. Splatting arrays of values into a commandlet also does not cause problems, since splatting an array is always interpreted as providing values for positional parameters (thus they cannot be confused with parameter names), and splatting hashtables is of course unambiguous (keys are always parameter names, values are always parameter values). So `$foo = @('-Path'); gc @foo` is also fine. Since commandlet parameters are typed, there is also no problem with filenames containing `\n`, etc, since a single string is a single string no matter what characters it contains. Printing strings containing control characters is probably a problem on Win 10's conhost and Linux terminal emulators. I haven't checked but I would assume PS does not do anything special to escape strings containing such character codes before emitting them to `$Host`. `iex` (the PS equivalent of `eval`) of course has the problems you'd expect, but just like `eval` it is rarely necessary. Edit: Also, PS does not do glob expansion. Glob expansion is the responsibility of the commandlet / program being invoked, so it is also not possible for filenames to resemble parameter names in this way. gc * gc '*' gc -Path * are all equivalent.
- Arnavion 8y ago
  Also, PS does not consider string literals to be parameter names. So even if you do have a file named `-Path`, `gc '-Path'` is equivalent to `gc -Path '-Path'` and works fine.

tyingq 8y ago

It has different issues. Try creating a file called aux, for example. Or even aux.js: https://github.com/gajus/react-aux/issues/10 https://github.com/gajus/react-aux/issues/10 See: https://docs.microsoft.com/en-us/windows/desktop/fileio/naming-a-file https://docs.microsoft.com/en-us/windows/desktop/fileio/nami...

Arnavion 8y ago
>It has different issues. To clarify the "it" here, NTFS allows you to create a file named `aux.js` just fine. The thing that injects special handling of `aux.js` is the Windows object layer that sits on top of it. CreateFileW(LR"#(\\?\C:\Users\Arnavion\Desktop\aux.js)#", GENERIC_WRITE, 0, nullptr, CREATE_NEW, 0, nullptr) will create a file named `aux.js` just fine, since it tells the Windows layer to not normalize names, which includes disabling the special handling of files named `aux`.
- tyingq 8y ago
  The main thread is discussing, for example, Unix filenames with newlines, which can similarly be created with ease, but cause problems later with other tools.

Arnavion 8y ago

NTFS is not too different from Linux filesystems. It allows any characters except `\` and `\0` in path components (explorer blocks a few more but that can be bypassed using namespaced paths). As for PS, commandlets with parameters do not have a problem with filenames being mistaken for parameters. Eg `gc $foo` will never parse the contents of `$foo` as a parameter name and always as the value of the (implicit) `-Path` parameter. Splatting arrays of values into a commandlet also does not cause problems, since splatting an array is always interpreted as providing values for positional parameters (thus they cannot be confused with parameter names), and splatting hashtables is of course unambiguous (keys are always parameter names, values are always parameter values). So `$foo = @('-Path'); gc @foo` is also fine. Since commandlet parameters are typed, there is also no problem with filenames containing `\n`, etc, since a single string is a single string no matter what characters it contains. Printing strings containing control characters is probably a problem on Win 10's conhost and Linux terminal emulators. I haven't checked but I would assume PS does not do anything special to escape strings containing such character codes before emitting them to `$Host`. `iex` (the PS equivalent of `eval`) of course has the problems you'd expect, but just like `eval` it is rarely necessary. Edit: Also, PS does not do glob expansion. Glob expansion is the responsibility of the commandlet / program being invoked, so it is also not possible for filenames to resemble parameter names in this way. gc * gc '*' gc -Path * are all equivalent.

Arnavion 8y ago
Also, PS does not consider string literals to be parameter names. So even if you do have a file named `-Path`, `gc '-Path'` is equivalent to `gc -Path '-Path'` and works fine.