On 2017-03-17 00:25, David Haller wrote:
Carlos: let me state it plain and simple: In Unix and Linux, _ALL_ characters but ASCII NUL '\0' and the slash '/'
Yes, I know. Since ever. They are valid.
Using '-' as the char to indicate options is just a convention. C.f. DOS and (older) Windows uses / instead (c.f. 'dir /?' as an example for DOS).
Yes, I know.
And there's nothing, but convention, for an UNIX-program not to use '+' (see 'set' or 'date'), or '/' or '#' or whatnot as an option char. Luckily, option-parsing is tedious, and thus most use some lib or other, e.g. getopt(3), and thus conventions usually apply.
In MsDos you could have a file named -something or /something (I think) and the program would never interpret that as a command or option. It would always be a file. There is no globing, the command line is passed exactly as written to the command, never expanded. It is the command who expands later what it thinks is a pattern by calling findfirst and findnext functions.
And when globbing turns out to expand a '?' or a '*' to a file named like something like an option, heh, the shell don't care. It calls the command with the expanded argument list.
Yes, I know. But some of the implications of this I was not aware in my RAM.
No, it is not so, not in Linux. The shell expands the '*' and gets all options and filenames as just strings in the same command line. MsDos doesn't get this confusion, it is the app which has to do the expansion after it parses the command line.
And exactly that is one of the _big_ fallacies of DOS. Each command has to parse its command line, and *implement globbing*, option parsing, argument handling, in non-specified order.
No, it is not a fallacy. It is a different method, and has advantages (and disadvantages). The user is in less danger of errors. You do not have to study a long manual to use the shell. C had library functions to parse the command line, IIRC.
With a UNIX shell, all is clear. The shell does expansion, globbing etc., the command does option-parsing (e.g. via getopt(3) e.g. via getopt(1)), and what remains is arguments, and all is clear.
No, it is not clear at all. Only to some. You only have to count the number of posts by people confused by this. Millions.
Sorry, but shell expansion is basics. If you managed to go 20 years without knowing how the shell works, that doesn't mean it was secret hidden unfathomable knowledge. The fault is yours not the shells.
I know the parts of how the shell works that I have needed, and yes, I have read the manual more than once. And I wrote many scripts. I simply did not notice the implications of a file named "-c".
The '-c' has nothing to do with this,
The -c is just a sample file named '-c'. Don't get confused.
And over the decades, I've had to use the -- feature a few times. I don't recall how I came to know it existed, but I learned why due to need.
There's plenty bugs pending in various much used scripts of many programs lacking a '--' to end option parsing.
Oh, and BTW: what do you think happens, if you type in
$ ls foo/a<TAB><TAB>
in bash? Yes, it shows you the result of globbing
foo/a*
I know. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" (Minas Tirith))