On Thu, 16 Mar 2017, Greg Freemyer wrote:
On Thu, Mar 16, 2017 at 5:16 PM, Carlos E. R.
> On 2017-03-16 20:13, Brian K. White wrote:
>> On 3/16/2017 2:13 PM, Carlos E. R. wrote:
>>> On 2017-03-16 18:04, David Haller wrote:
>>>> *Gah* Don't you learn the absolute basics of the shell you use
>>>> Why in the world should rm act otherwise when you call it with the
>>>> '-i' option? No matter if you typed the -i or if it is the
>>> Well, no, I was not aware of this. And I have been using the Linux shell
>>> bash for almost two decades.
And you've not learned that the shell does globbing??? *yikes* I pity you.
>>> I thought, without thinking, that the
command would differentiate
>>> between options and filenames automatically.
Carlos: let me state it plain and simple: In Unix and Linux, _ALL_
characters but ASCII NUL '\0' and the slash '/'
==== man ascii ====
Oct Dec Hex Char
000 0 00 NUL '\0'
057 47 2F /
are valid chars in a filename. Even at the start. And this explicitly
includes a '-' as the first char of a filename (and dirname). And
ISO-8859-* and UTF* are supersets of ASCII, and the same applies.
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). 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.
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. See my examples. BTW: for
experiments, I suggest using 'ls' as command and e.g. '-m' as
>>> 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.
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.
>> 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, that was just to call each shell
in the same way and show that _all_ handle the problem the same way,
and csh, zsh and bourne (bash) mark extreme points on what's available
as shells on UNIX and Linux. The '-c' just tells the shell to execute
the argument string as if it were entered manually in a shell.
If you're already using bash, the following three commandlines are
$ ( set -x; ls -1 | head -n 1; )
$ bash -c 'set -x; ls -1 | head -n 1;'
$ bash -x -c 'ls -1 | head -n 1'
All three start a new subshell, set the 'x' option, run 'ls -1' and
pipe the output of that ls to 'head -n 1'...
You can do all that with the other shells, except the first form
requires you running that shell already.
Not all shells have the 'set -x' though, e.g.:
$ tcsh -c 'set -x; ls -1 | head -n 1;'
set: Variable name must begin with a letter.
But, then again, tcsh has the -x option, and that'll work:
$ tcsh -x -c 'ls -1 | head -n 1;'
head -n 1
Be especially sure not to create to files "-rf" and "/"
Aye regarding the './-rf' *eg*, but at least, you won't be able to
create the file '/'. But an extra space in the wrong place can be just
as disatrous, e.g.
# rm -rf /* ~
^ that invisible lil' bugger
DO NOT TRY THIS AT HOME! OR ANYWHERE!
WHY? FUCKING ASK THE SHELL!
$ echo rm -rf /* ~
rm -rf /bin /boot /dev /etc [..]
DO NOT EVEN DARE THINK ABOUT TESTING SHELL-GLOBBING WITH THOSE
use e.g. 'rm -f ./*~' vs. 'rm -f ./* ~' in a specially created dir
under e.g /tmp. And then touch e.g. the file './-i' and omit the './'
And if a string containing a filename with '-rf /' get's evaled
somewhere, doom followeth... There's tons of CVEs about that, I think
(probably most of PHP or somesuch system() calls on user-supplied
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
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
$ ls foo/a*
would show. bash_completion might interfere though, which is quite
another long rant and pet peeve by me (with 'cd', I can see filtering
it to dirs only, but with e.g. mplayer or vlc? Both will happily play
foo.foo, as long as that's a file it can play (music, video, playlist,
URI), disregarding the name completely. But bash_completion will deny
you completing the filename, as it's stupidly confined to some
predefined extensions. Hey, WhenTF have file-extensions ever been
relevant under UNIX/Linux??? *gah*
So, again: Learn the effin' basics of the shell! There's tons of good
tutorials out there. And it's all in the man-/infopage too, just a bit
harder to find and to read, but "the definitive source" (besides the
actual source ;)
Oh, and try
$ gunzip -dc $(man -w bash) | man2html > bash.html
$ xdg-open bash.html
if you're allergic to the terminal ;)
There's also way's to convert manpages to nice pdf files, IIRC.
-dnh, pining for the days when a friend and he were working out
the subtleties of quoting semantics of bash in variable
assignments ... And the differences between `` and $().
In the middle of evil there's allways *vi* -- snarfed from "Sensor"
To unsubscribe, e-mail: opensuse+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse+owner(a)opensuse.org