Marc Chamberlin wrote:

Ok I am puzzled, why does grep fail ...

Here is an example of a failure using a simple grep command -

darkstar:/usr/lib/systemd/system # grep run * grep: invalid option -- '.' Usage: grep [OPTION]... PATTERN [FILE]...

Try grep -- run * Likely some file name is being taken as a grep option. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 03/16/2017 06:33 AM, Marc Chamberlin wrote:

On 03/15/2017 09:45 PM, L A Walsh wrote:

...

Marc Chamberlin wrote:

...

darkstar:/usr/lib/systemd/system # grep run * grep: invalid option -- '.' Usage: grep [OPTION]... PATTERN [FILE]...

Try grep -- run *

Likely some file name is being taken as a grep option.

OKeyDoKey! Didn't see that one coming or in the documentation! A magic dash dash does the trick! Thanks L A Walsh for the proper incantation.

This is common to most-to-all command-line utilities using the library functions getopt(3)/getopt_long(3) to parse options ('man getopt_long'). In coreutils, this is documented in "common options": https://www.gnu.org/software/coreutils/manual/html_node/Common-options.html#... ‘--’ Delimit the option list. Later arguments, if any, are treated as operands even if they begin with ‘-’. For example, ‘sort -- -r’ reads from the file named -r. And there's also an FAQ entry: https://www.gnu.org/software/coreutils/faq/coreutils-faq.html#How-do-I-remov... I'm wondering why this isn't mentioned in grep's documentation ... yet: you should ask to add it to the documentation on the grep mailing list (mailto:bug-grep@gnu.org) - a wonderful start to contribute to open source. ;-) Have a nice day, Berny -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 03/16/2017 09:06 AM, Andrei Borzenkov wrote:

On Thu, Mar 16, 2017 at 10:43 AM, Bernhard Voelker wrote:

...

In coreutils, this is documented in "common options":

...

...

I'm wondering why this isn't mentioned in grep's documentation

Why should it be mentioned in every individual utility if this is already mentioned in common options and behavior is exactly the same for every program? Because disk space is cheap today?

grep != coreutils Have a nice day, Berny -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Hello, On Thu, 16 Mar 2017, Bernhard Voelker wrote: [..]

This is common to most-to-all command-line utilities using the library functions getopt(3)/getopt_long(3) to parse options ('man getopt_long').

In coreutils, this is documented in "common options":

https://www.gnu.org/software/coreutils/manual/html_node/Common-options.html#...

'--'

Delimit the option list. Later arguments, if any, are treated as operands even if they begin with '-'. For example, 'sort -- -r' reads from the file named -r. [..] I'm wondering why this isn't mentioned in grep's documentation

Because it is only relevant in the shell, where the '*' gets expanded. And that is documented there. If you have a file somewhere named '-i', and call e.g. 'rm *', the *SHELL* expands the '*' and thus rm gets called with the argument and in this case option '-i' somewhere in the call! E.g.: $ ls -1 -i a b $ bash -x -c 'rm -v * ' + rm -v -i a b #### note this is the line! rm: remove regular empty file `a'? n rm: remove regular empty file `b'? n $ csh -x -c 'rm -v * ' rm -v -i a b #### note this is the line! rm: remove regular empty file `a'? n rm: remove regular empty file `b'? n $ zsh -x -c 'rm -v * ' +zsh:1> rm -v -i a b #### note this is the line! rm: remove regular empty file `a'? n rm: remove regular empty file `b'? n And (t)csh is about as different from bourne/ksh/zsh as it gets. *Gah* Don't you learn the absolute basics of the shell you use anymore? 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 result of globbing? Having '--' as a stop-gap to end options in getopt(3) is just convienience. And _any_ CLI tool taking options, whether using getopt(3) or something else will get called with e.g. '-i' and react on it, unless you use '--' where taken, or the './' prefix or a full path. To sum it up: this all belongs into the shell-documentation, where it is, and not into the documentation of every program taking options on the command line. HAND, -dnh -- River: "Also, I can kill you with my brain." --Episode #11, "Trash" -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 3/16/2017 2:13 PM, Carlos E. R. wrote:

On 2017-03-16 18:04, David Haller wrote:

...

Hello,

...

*Gah* Don't you learn the absolute basics of the shell you use anymore?

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 result of globbing?

Well, no, I was not aware of this. And I have been using the Linux shell bash for almost two decades.

I thought, without thinking, that the command would differentiate between options and filenames automatically. 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.

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. And the windows cmd command line parsing is absolutely terrible example. You may not understand or like the rules that all of the unix shells follow, but the at least have rules, which they follow, and which are consistent and predictable and allow you to express anything you need. The same is NOT true of cmd.exe. The quoting and command line parsing rules for that were drawn by kindergarteners in crayon. --- To launch a batch script with spaces in the Program Path requiring "quotes" CMD /k ""c:\batch files\test.cmd" "Parameter 1 with space" "Parameter2 with space"" --- That is some amazing embarassing stuff right there. If a developer brought that to me I wouldn't fire them, but they'd sure know that they failed to meet a pretty low bar. And yet, sucky as that is, When I had to write some windows software that needed to run a program, from cmd.exe from within an execve(), and then that had to be run from a registry entry, which recieved commandline arguments from a URL... I found the docs and learned how it works. Quoting, escaping, globbing, and the way those all behave in different contexts and interact with each other, including nested within each other, these are all simply required understanding to use the system in any better way than guessing and luck. Otherwise you will never know what will happen with any command you ever write, and you will hit exactly what you hit. -- bkw -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On Thu, Mar 16, 2017 at 5:16 PM, Carlos E. R. wrote:

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:

...

Hello,

...

*Gah* Don't you learn the absolute basics of the shell you use anymore?

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 result of globbing?

Well, no, I was not aware of this. And I have been using the Linux shell bash for almost two decades.

I thought, without thinking, that the command would differentiate between options and filenames automatically. 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.

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".

Carlos, Be especially sure not to create to files "-rf" and "/" I've never tried it, but I assume "rm *" in that folder could do "rm -rf /" 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. Greg -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Hello, On Thu, 16 Mar 2017, Greg Freemyer wrote:

On Thu, Mar 16, 2017 at 5:16 PM, Carlos E. R. wrote:

...

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 anymore?

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 result of globbing?

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 filename or such.

...

...

...

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 equivalent: $ ( 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;' ls -1 head -n 1 [first filename]

Carlos,

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 PATTERNS! 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 strings).

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.e. what $ 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@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Hello, On Fri, 17 Mar 2017, Bernhard Voelker wrote:

On 03/16/2017 10:31 PM, Greg Freemyer wrote:

...

Be especially sure not to create to files "-rf" and "/"

I've never tried it, but I assume "rm *" in that folder could do "rm -rf /"

Not too scary - GNU rm has a failsafe for the '/' argument (including links and unusual ".." namings to it):

$ rm -rf / rm: it is dangerous to operate recursively on '/' rm: use --no-preserve-root to override this failsafe

... as long as you don't create a file named "--no-preserve-root". ;-)

Ooooch mennooo! That takes out all the fun! Hasn't it been the lore, that if you've not once accidentally run 'rm -rf /' or at least 'rm -rf ~', you're no UNIX/Linux guy? Or at least: you deleted some files via a tyop, and learned from it. Either by coping with the loss (you had backups, din'tya?) or the hard way using debugfs. Well, I hope that after many years, that I've learned to enter a Ctrl-c unless I'm _REALLY_ sure (triple-, quadruple-checked) the commandline I've just entered.. 'dd if=/dev/zero of=/dev/sdNOSUCHDEV' anyone? where NOSUCHDEV actually is something like 'c' or such ;) -dnh --

Wow, and everyone swears [Python]'s better than Perl. Wait, you don't say it's worse, never mind. -- Satya The axis on which Perl sits is rotated 90 degrees with respect to the rest of language-goodness-space. -- Garrett Wollman

-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Wow! I had no idea my simple question would create such a thread of thoughts! As someone who has written a LOT of compilers and parsers in my career, IMHO this boils down to a classic case of a faulty language design. Technical wizardry v.s intuitive understanding... The command - grep run * is read intuitively, by most users, to semantically mean "Search all the files in this directory for the string "run" and report back where the string was found. but apparently the technical implementation misses this intent and overloads the "run" parameter with two possible interpretations - is it a pattern or is it a file name? Allowing this ambiguity to occur is a fault of the shell language, ergo that is why I make the aforementioned claim. One of the more difficult aspects of human/machine language theory is to design a language that avoids such ambiguities... As long as this ambiguity is allowed to remain, no amount of documentation will ever resolve the problem of users running into such difficulties like I did. The right solution is to either fix the shell to fulfill the intuitive intent of the command, or to fix the syntax so that this kind of ambiguous mistake cannot be made. I noted, with some amusement, the usage of other shell command patterns to rationalize the requirement of the double dashes to overcome the issue I raised with the grep command. That is scary because it is exposing an endemic problem that is affecting a lot of other commands and potentially creating a lot of user confusion with a wide variety of shell commands. The goal of computer language design should be to make it easier for humans to communicate with machines, not harder! It is not a good goal to be creating technical wizards who develop deep understanding of subtle nuances. Marc... -- "The Truth is out there" - Spooky -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 03/16/2017 06:44 PM, David T-G wrote:

Marc, et al --

...and then Marc Chamberlin said... % ... % % grep run * % ... % but apparently the technical implementation misses this intent and % overloads the "run" parameter with two possible interpretations - is % it a pattern or is it a file name? Allowing this ambiguity to occur [snip]

Wait, what?

grep insists that the first pattern it gets is its search pattern. Even if you have a file called 'run' in the current directory, it's going to look for that string. If you don't put anything after the pattern, it's going to search stdin.

Then Hann, I refer you back to my original posting asking why this simple grep command failed in certain directories? The answer that I got, (at least my interpretation of the answers) was that it failed because there are file names in the directory which had the string "run" within the filename... Hence the need for the double dashes as the first parameter in order to get this grep command to work.. Please review this thread from the beginning... Marc.. -- "The Truth is out there" - Spooky -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Marc -- ...and then Marc Chamberlin said... % % On 03/16/2017 06:44 PM, David T-G wrote: % > ... % >grep insists that the first pattern it gets is its search pattern. Even % >if you have a file called 'run' in the current directory, it's going to % >look for that string. If you don't put anything after the pattern, it's % >going to search stdin. % % Then Hann, I refer you back to my original posting asking why this % simple grep command failed in certain directories? The answer that I Did you ever provide a listing of the contents of your example directory? I've been watching this thread, and if you sent it I must have missed it. I'm very interested in what that period-space appears to be and how it played into your command line, not least because * does not pick up "hidden" files (those starting with a period). % got, (at least my interpretation of the answers) was that it failed % because there are file names in the directory which had the string % "run" within the filename... Hence the need for the double dashes as I believe your interpretation is incorrect. % the first parameter in order to get this grep command to work.. % Please review this thread from the beginning... I just went back and looked again, and I still don't see any further diagnostic information from you. If you wish an explanation of the cause beyond Linda's excellent suggestion to de-argument-ify the tokens on the command line, you should show us with what you're working. % % Marc.. HANN again & I'm off to bed to see the rest of this tomorrow :-) :-D -- David T-G See http://justpickone.org/davidtg/email/ See http://justpickone.org/davidtg/tofu.txt -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 2017-03-17 00:26, Greg Freemyer wrote:

On Thu, Mar 16, 2017 at 7:20 PM, Bernhard Voelker wrote:

...

On 03/16/2017 10:31 PM, Greg Freemyer wrote:

...

Be especially sure not to create to files "-rf" and "/"

I've never tried it, but I assume "rm *" in that folder could do "rm -rf /"

Not too scary - GNU rm has a failsafe for the '/' argument (including links and unusual ".." namings to it):

$ rm -rf / rm: it is dangerous to operate recursively on ‘/’ rm: use --no-preserve-root to override this failsafe

... as long as you don't create a file named "--no-preserve-root". ;-) At least you'll get this failsafe behavior with rm(1) from GNU coreutils, so I can't tell for other flavors (HP-UX, Solaris, ...).

Thanks Berny,

That is one command I won't be testing out any time soon.

I have been scared of that command all my life. Well, all my life soon after I found Linux, that is :-) -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" (Minas Tirith))

16.03.2017 21:13, Carlos E. R. пишет:

On 2017-03-16 18:04, David Haller wrote:

...

Hello,

...

*Gah* Don't you learn the absolute basics of the shell you use anymore?

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 result of globbing?

Well, no, I was not aware of this. And I have been using the Linux shell bash for almost two decades.

http://www.vbcf.ac.at/fileadmin/user_upload/BioComp/training/unix_haters_han... Page 19

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))

Carlos E. R. wrote:

I thought, without thinking, that the command would differentiate between options and filenames automatically. 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.

---- It's very much the same way in linux -- in MsDOS, a Win32 lib is called to open a dir and sift through the entries. In linux, a dir is opened and a .so lib is called process the dir format and return info. MS-DOS, maybe didn't have the confusion, but as soon as NT hit and supported WinServer2000 & XP, the direct-access MS-DOS model became a a relic. Vista and Win7 added another level(or more) of hardware virtualization, and more indirection was added in Win8 & 10, with Win10 -- so if anything, Windows has ALOT more confusion with it showing in how many "updates" released by MS have unforeseen effects and "bluescreen" / no-boot problems. Linux (the kernel) has considerably fewer "blue-screen" events that disable a system booting. A notable uptick in problems preventing booting w/no easy fix has risen in the past few-to-several years with as traditional and incremental development has been replaced with large, "one-way" systems that don't co-exist with the previous development & design model. Unfortunate. "One-wayism" is as hazardous to the linux ecosystem as monotheism and mono-political systems are to the human ecosystem. C'est la vie. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 03/16/2017 07:57 PM, David T-G wrote:

Marc --

...and then Marc Chamberlin said... % % On 03/16/2017 06:44 PM, David T-G wrote: % > ... % >grep insists that the first pattern it gets is its search pattern. Even % >if you have a file called 'run' in the current directory, it's going to % >look for that string. If you don't put anything after the pattern, it's % >going to search stdin. % % Then Hann, I refer you back to my original posting asking why this % simple grep command failed in certain directories? The answer that I

Did you ever provide a listing of the contents of your example directory? I've been watching this thread, and if you sent it I must have missed it.

I'm very interested in what that period-space appears to be and how it played into your command line, not least because

*

does not pick up "hidden" files (those starting with a period).

David - I can certainly provide a listing for you, but I suspect you could probably try this on your own systems... I had cd'd to /usr/lib/systemd/system and was curious as to how other services were initializing pid files and directories in the temporary /run and /var/run directories. So I thought I would do a grep for the string "run" to see if I could get a clue.. (I am setting up Bacula on my systems and needed to create the .service files for it, and yes I have now figured out how to initialize directories and files in /run.) So here is a full listing of what is in my /usr/lib/systemd/system directory (sorry there is a lot of files there, so this is going to be long and noisy, but I want to be thorough and not leave any necessary info out...) darkstar:/usr/lib/systemd/system # ls -al total 1328 drwxr-xr-x 32 root root 20480 Mar 15 20:53 . drwxr-xr-x 15 root root 4096 Feb 4 19:06 .. -rw-r--r-- 1 root root 747 Oct 9 02:23 accounts-daemon.service -rw-r--r-- 1 root root 497 Jan 25 01:07 after-local.service -rw-r--r-- 1 root root 459 Oct 7 19:18 alsa-restore.service lrwxrwxrwx 1 root root 20 Feb 4 11:51 alsasound.service -> alsa-restore.service -rw-r--r-- 1 root root 410 Oct 7 19:18 alsa-state.service -rw-r--r-- 1 root root 378 Feb 1 12:33 apparmor.service -rw-r--r-- 1 root root 160 Oct 28 10:14 atd.service -rw-r--r-- 1 root root 621 Oct 1 01:02 auditd.service -rw-r--r-- 1 root root 686 Oct 28 12:11 auth-rpcgss-module.service -rw-r--r-- 1 root root 464 Nov 4 03:58 autofs.service lrwxrwxrwx 1 root root 14 Feb 4 19:06 autovt@.service -> getty@.service -rw-r--r-- 1 root root 433 Dec 2 03:10 autoyast-initscripts.service -rw-r--r-- 1 root root 1044 Oct 7 16:51 avahi-daemon.service -rw-r--r-- 1 root root 870 Oct 7 16:51 avahi-daemon.socket -rw-r--r-- 1 root root 976 Oct 7 16:51 avahi-dnsconfd.service -rw-r--r-- 1 root root 1001 Feb 28 23:02 bacula-dir.service -rw-r--r-- 1 root root 944 Nov 16 02:51 bacula-dir.service~ -rw-r--r-- 1 root root 878 Mar 15 20:19 bacula-fd.service -rw-r--r-- 1 root root 880 Feb 28 23:01 bacula-fd.service~ -rw-r--r-- 1 root root 884 Feb 28 23:02 bacula-sd.service -rw-r--r-- 1 root root 827 Nov 16 02:51 bacula-sd.service~ -rw-r--r-- 1 root root 877 Jan 25 01:07 basic.target drwxr-xr-x 2 root root 4096 Jan 25 01:07 basic.target.wants -r--r--r-- 1 root root 360 Oct 18 21:45 blk-availability.service -rw-r--r-- 1 root root 420 Oct 7 19:18 bluetooth.service -rw-r--r-- 1 root root 379 Jan 25 01:07 bluetooth.target -rw-r--r-- 1 root root 744 Mar 1 02:39 boinc-client.service -rw-r--r-- 1 root root 231 Oct 28 12:10 btrfsmaintenance-refresh.service -rw-r--r-- 1 root root 358 Jan 25 01:07 busnames.target drwxr-xr-x 2 root root 4096 Feb 4 19:06 busnames.target.wants -rw-r--r-- 1 root root 154 Sep 6 2016 configure-printer@.service -rw-r--r-- 1 root root 770 Jan 25 01:07 console-getty.service -rw-r--r-- 1 root root 750 Jan 25 01:07 console-shell.service -rw-r--r-- 1 root root 791 Jan 25 01:07 container-getty@.service -rw-r--r-- 1 root root 276 Oct 18 05:33 cron.service -rw-r--r-- 1 root root 394 Jan 25 01:07 cryptsetup-pre.target -rw-r--r-- 1 root root 366 Jan 25 01:07 cryptsetup.target lrwxrwxrwx 1 root root 13 Feb 4 19:06 ctrl-alt-del.target -> reboot.target -rw-r--r-- 1 root root 225 Jun 26 2015 cups-browsed.service -rw-r--r-- 1 root root 141 Oct 9 14:07 cups.service lrwxrwxrwx 1 root root 25 Feb 4 19:06 dbus-org.freedesktop.hostname1.service -> systemd-hostnamed.service lrwxrwxrwx 1 root root 23 Feb 4 19:06 dbus-org.freedesktop.import1.service -> systemd-importd.service lrwxrwxrwx 1 root root 23 Feb 4 19:06 dbus-org.freedesktop.locale1.service -> systemd-localed.service lrwxrwxrwx 1 root root 22 Feb 4 19:06 dbus-org.freedesktop.login1.service -> systemd-logind.service lrwxrwxrwx 1 root root 24 Feb 4 19:06 dbus-org.freedesktop.machine1.service -> systemd-machined.service lrwxrwxrwx 1 root root 25 Feb 4 19:06 dbus-org.freedesktop.timedate1.service -> systemd-timedated.service -rw-r--r-- 1 root root 358 Oct 30 08:58 dbus.service -rw-r--r-- 1 root root 102 Oct 30 08:58 dbus.socket drwxr-xr-x 2 root root 4096 Jan 25 01:07 dbus.target.wants -rw-r--r-- 1 root root 1010 Jan 25 01:07 debug-shell.service lrwxrwxrwx 1 root root 16 Feb 4 19:06 default.target -> graphical.target drwxr-xr-x 2 root root 4096 Jan 25 01:07 default.target.wants -rw-r--r-- 1 root root 670 Jan 25 01:07 dev-hugepages.mount -rw-r--r-- 1 root root 590 Jan 25 01:07 dev-mqueue.mount -r--r--r-- 1 root root 675 Dec 5 04:49 display-manager.service -r--r--r-- 1 root root 330 Oct 18 21:45 dm-event.service -r--r--r-- 1 root root 248 Oct 18 21:45 dm-event.socket -rw-r--r-- 1 root root 400 Oct 7 19:12 dmraid-activation.service -rw-r--r-- 1 root root 431 Dec 23 09:10 dnsmasq.service lrwxrwxrwx 1 root root 62 Feb 4 19:06 dracut-cmdline.service -> ../../dracut/modules.d/98dracut-systemd/dracut-cmdline.service lrwxrwxrwx 1 root root 64 Feb 4 19:06 dracut-initqueue.service -> ../../dracut/modules.d/98dracut-systemd/dracut-initqueue.service lrwxrwxrwx 1 root root 60 Feb 4 19:06 dracut-mount.service -> ../../dracut/modules.d/98dracut-systemd/dracut-mount.service lrwxrwxrwx 1 root root 64 Feb 4 19:06 dracut-pre-mount.service -> ../../dracut/modules.d/98dracut-systemd/dracut-pre-mount.service lrwxrwxrwx 1 root root 64 Feb 4 19:06 dracut-pre-pivot.service -> ../../dracut/modules.d/98dracut-systemd/dracut-pre-pivot.service lrwxrwxrwx 1 root root 66 Feb 4 19:06 dracut-pre-trigger.service -> ../../dracut/modules.d/98dracut-systemd/dracut-pre-trigger.service lrwxrwxrwx 1 root root 63 Feb 4 19:06 dracut-pre-udev.service -> ../../dracut/modules.d/98dracut-systemd/dracut-pre-udev.service lrwxrwxrwx 1 root root 63 Feb 4 19:06 dracut-shutdown.service -> ../../dracut/modules.d/98dracut-systemd/dracut-shutdown.service -rw-r--r-- 1 root root 1021 Jan 25 01:07 emergency.service -rw-r--r-- 1 root root 431 Jan 25 01:07 emergency.target -rw-r--r-- 1 root root 501 Jan 25 01:07 exit.target -rw-r--r-- 1 root root 440 Jan 25 01:07 final.target -rw-r--r-- 1 root root 95 Feb 23 01:14 fstrim.service -rw-r--r-- 1 root root 170 Feb 23 01:14 fstrim.timer -rw-r--r-- 1 root root 1561 Jan 25 01:07 getty@.service -rw-r--r-- 1 root root 460 Jan 25 01:07 getty.target drwxr-xr-x 2 root root 4096 Feb 4 19:06 getty@tty1.service.d -rw-r--r-- 1 root root 424 Oct 18 02:55 gpm.service -rw-r--r-- 1 root root 558 Jan 25 01:07 graphical.target drwxr-xr-x 2 root root 4096 Feb 4 19:06 graphical.target.wants -rw-r--r-- 1 root root 402 Jan 23 03:20 grub2-once.service -rw-r--r-- 1 root root 571 Jan 25 01:07 halt-local.service -rw-r--r-- 1 root root 487 Jan 25 01:07 halt.target drwxr-xr-x 2 root root 4096 Jan 25 01:07 halt.target.wants -rw-r--r-- 1 root root 572 Oct 7 10:11 haveged.service -rw-r--r-- 1 root root 447 Jan 25 01:07 hibernate.target -rw-r--r-- 1 root root 468 Jan 25 01:07 hybrid-sleep.target -rw-r--r-- 1 root root 634 Jan 25 01:07 initrd-cleanup.service -rw-r--r-- 1 root root 553 Jan 25 01:07 initrd-fs.target -rw-r--r-- 1 root root 802 Jan 25 01:07 initrd-parse-etc.service -rw-r--r-- 1 root root 526 Jan 25 01:07 initrd-root-fs.target -rw-r--r-- 1 root root 644 Jan 25 01:07 initrd-switch-root.service -rw-r--r-- 1 root root 691 Jan 25 01:07 initrd-switch-root.target drwxr-xr-x 2 root root 4096 Feb 4 11:58 initrd-switch-root.target.wants -rw-r--r-- 1 root root 671 Jan 25 01:07 initrd.target drwxr-xr-x 2 root root 4096 Feb 4 19:06 initrd.target.wants -rw-r--r-- 1 root root 668 Jan 25 01:07 initrd-udevadm-cleanup-db.service -rw-r--r-- 1 root root 207 Jan 5 13:24 irqbalance.service -rw-r--r-- 1 root root 316 Nov 24 23:30 iscsid.service -rw-r--r-- 1 root root 191 Nov 24 23:30 iscsid.socket -rw-r--r-- 1 root root 471 Nov 24 23:30 iscsi.service -rw-r--r-- 1 root root 352 Nov 24 23:30 iscsiuio.service -rw-r--r-- 1 root root 165 Nov 24 23:30 iscsiuio.socket -rw-r--r-- 1 root root 257 Oct 7 20:50 kexec-load.service -rw-r--r-- 1 root root 501 Jan 25 01:07 kexec.target drwxr-xr-x 2 root root 4096 Jan 25 01:07 kexec.target.wants -rw-r--r-- 1 root root 1067 Oct 7 10:04 klogd.service -rw-r--r-- 1 root root 1267 Oct 7 10:04 klog.service -rw-r--r-- 1 root root 679 Jan 25 01:07 kmod-static-nodes.service -rw-r--r-- 1 root root 670 Mar 2 13:16 kodi.service -rw-r--r-- 1 root root 178 Mar 5 04:30 ksysguardd.service -rw-r--r-- 1 root root 658 Jan 25 01:07 ldconfig.service -rw-r--r-- 1 root root 395 Jan 25 01:07 local-fs-pre.target -rw-r--r-- 1 root root 507 Jan 25 01:07 local-fs.target drwxr-xr-x 2 root root 4096 Feb 4 19:06 local-fs.target.wants -rw-r--r-- 1 root root 238 Dec 17 04:49 lunmask.service -r--r--r-- 1 root root 370 Oct 18 21:45 lvm2-lvmetad.service -r--r--r-- 1 root root 197 Oct 18 21:45 lvm2-lvmetad.socket -r--r--r-- 1 root root 654 Oct 18 21:45 lvm2-monitor.service -r--r--r-- 1 root root 382 Oct 18 21:45 lvm2-pvscan@.service -rw-r--r-- 1 root root 405 Jan 25 01:07 machine.slice -rw-r--r-- 1 root root 531 Jan 25 01:07 machines.target -rw-r--r-- 1 root root 261 Jul 21 2016 mcelog.service -rw-r--r-- 1 root root 481 Oct 7 18:34 mdadm-grow-continue@.service -rw-r--r-- 1 root root 187 Oct 7 18:34 mdadm-last-resort@.service -rw-r--r-- 1 root root 176 Oct 7 18:34 mdadm-last-resort@.timer -rw-r--r-- 1 root root 531 Oct 7 18:34 mdmonitor.service -rw-r--r-- 1 root root 1034 Oct 7 18:34 mdmon@.service -rw-r--r-- 1 root root 268 Jan 6 10:59 ModemManager.service -rw-r--r-- 1 root root 492 Jan 25 01:07 multi-user.target drwxr-xr-x 2 root root 4096 Feb 4 19:06 multi-user.target.wants -rw-r--r-- 1 root root 429 Feb 7 05:28 mysql.service -rw-r--r-- 1 root root 457 Feb 7 05:28 mysql@.service -rw-r--r-- 1 root root 64 Feb 7 05:28 mysql.target -rw-r--r-- 1 root root 349 Oct 8 05:39 NetworkManager-dispatcher.service -rw-r--r-- 1 root root 466 Oct 8 05:39 NetworkManager.service -rw-r--r-- 1 root root 458 Oct 8 05:39 NetworkManager-wait-online.service -rw-r--r-- 1 root root 464 Jan 25 01:07 network-online.target drwxr-xr-x 2 root root 4096 Feb 4 12:02 network-online.target.wants -rw-r--r-- 1 root root 461 Jan 25 01:07 network-pre.target -rw-r--r-- 1 root root 480 Jan 25 01:07 network.target -rw-r--r-- 1 root root 372 Oct 28 12:11 nfs-blkmap.service -rw-r--r-- 1 root root 433 Oct 28 12:11 nfs-client.target drwxr-xr-x 2 root root 4096 Feb 4 11:57 nfs-client.target.d -rw-r--r-- 1 root root 375 Oct 28 12:11 nfs-config.service drwxr-xr-x 2 root root 4096 Feb 4 11:57 nfs-config.service.d -rw-r--r-- 1 root root 352 Oct 28 12:11 nfs-idmapd.service -rw-r--r-- 1 root root 825 Oct 28 12:11 nfs.service -rw-r--r-- 1 root root 567 Oct 28 12:11 nfs-utils.service -rw-r--r-- 1 root root 339 May 18 2016 nmb.service -rw-r--r-- 1 root root 507 Oct 18 03:10 nscd.service -rw-r--r-- 1 root root 514 Jan 25 01:07 nss-lookup.target -rw-r--r-- 1 root root 473 Jan 25 01:07 nss-user-lookup.target -rw-r--r-- 1 root root 410 Dec 19 09:18 ntpd.service -rw-r--r-- 1 root root 398 Dec 19 09:18 ntp-wait.service -rw-r--r-- 1 root root 455 Oct 28 12:13 openvpn@.service -rw-r--r-- 1 root root 97 Oct 28 12:13 openvpn.target -rw-r--r-- 1 root root 554 Jan 25 01:07 org.freedesktop.hostname1.busname -rw-r--r-- 1 root root 471 Jan 25 01:07 org.freedesktop.import1.busname -rw-r--r-- 1 root root 550 Jan 25 01:07 org.freedesktop.locale1.busname -rw-r--r-- 1 root root 598 Jan 25 01:07 org.freedesktop.login1.busname -rw-r--r-- 1 root root 549 Jan 25 01:07 org.freedesktop.machine1.busname -rw-r--r-- 1 root root 480 Jan 25 01:07 org.freedesktop.systemd1.busname -rw-r--r-- 1 root root 538 Jan 25 01:07 org.freedesktop.timedate1.busname -rw-r--r-- 1 root root 156 Oct 9 17:33 packagekit-offline-update.service -rw-r--r-- 1 root root 134 Oct 9 17:33 packagekit.service -rw-r--r-- 1 root root 354 Jan 25 01:07 paths.target -rw-r--r-- 1 root root 349 Oct 7 19:20 plymouth-halt.service -rw-r--r-- 1 root root 363 Oct 7 19:20 plymouth-kexec.service -rw-r--r-- 1 root root 358 Oct 7 19:20 plymouth-poweroff.service -rw-r--r-- 1 root root 225 Oct 7 19:20 plymouth-quit.service -rw-r--r-- 1 root root 231 Oct 7 19:20 plymouth-quit-wait.service -rw-r--r-- 1 root root 248 Oct 7 19:20 plymouth-read-write.service -rw-r--r-- 1 root root 339 Oct 7 19:20 plymouth-reboot.service -rw-r--r-- 1 root root 551 Oct 7 19:20 plymouth-start.service -rw-r--r-- 1 root root 295 Oct 7 19:20 plymouth-switch-root.service -rw-r--r-- 1 root root 172 Oct 28 10:36 polkit.service -rw-r--r-- 1 root root 1405 Oct 7 19:18 postfix.service -rw-r--r-- 1 root root 552 Jan 25 01:07 poweroff.target drwxr-xr-x 2 root root 4096 Feb 4 19:06 poweroff.target.wants -rw-r--r-- 1 root root 377 Jan 25 01:07 printer.target -rw-r--r-- 1 root root 693 Jan 25 01:07 proc-sys-fs-binfmt_misc.automount -rw-r--r-- 1 root root 603 Jan 25 01:07 proc-sys-fs-binfmt_misc.mount -rw-r--r-- 1 root root 272 Jan 17 03:17 purge-kernels.service -rw-r--r-- 1 root root 576 Jan 25 01:07 quotaon.service -rw-r--r-- 1 root root 646 Jan 25 01:07 rc-local.service -rw-r--r-- 1 root root 543 Jan 25 01:07 reboot.target drwxr-xr-x 2 root root 4096 Feb 4 19:06 reboot.target.wants -rw-r--r-- 1 root root 396 Jan 25 01:07 remote-fs-pre.target -rw-r--r-- 1 root root 482 Jan 25 01:07 remote-fs.target -rw-r--r-- 1 root root 997 Jan 25 01:07 rescue.service -rw-r--r-- 1 root root 509 Jan 25 01:07 rescue.target drwxr-xr-x 2 root root 4096 Feb 4 19:06 rescue.target.wants -rw-r--r-- 1 root root 266 Jun 27 2016 rng-tools.service -rw-r--r-- 1 root root 312 Oct 7 10:27 rpcbind.service -rw-r--r-- 1 root root 368 Oct 7 10:27 rpcbind.socket -rw-r--r-- 1 root root 500 Jan 25 01:07 rpcbind.target -rw-r--r-- 1 root root 407 Oct 28 12:11 rpc-gssd.service -rw-r--r-- 1 root root 463 Oct 28 12:11 rpc-statd-notify.service -rw-r--r-- 1 root root 429 Oct 28 12:11 rpc-statd.service -rw-r--r-- 1 root root 531 Oct 28 12:11 rpc-svcgssd.service -rw-r--r-- 1 root root 231 Oct 7 19:18 rsyncd.service -rw-r--r-- 1 root root 470 Jan 9 14:16 rsyslog.service -rw-r--r-- 1 root root 1253 Oct 8 04:39 rtkit-daemon.service lrwxrwxrwx 1 root root 15 Feb 4 19:06 runlevel0.target -> poweroff.target lrwxrwxrwx 1 root root 13 Feb 4 19:06 runlevel1.target -> rescue.target drwxr-xr-x 2 root root 4096 Jan 25 01:07 runlevel1.target.wants lrwxrwxrwx 1 root root 17 Feb 4 19:06 runlevel2.target -> multi-user.target drwxr-xr-x 2 root root 4096 Jan 25 01:07 runlevel2.target.wants lrwxrwxrwx 1 root root 17 Feb 4 19:06 runlevel3.target -> multi-user.target drwxr-xr-x 2 root root 4096 Jan 25 01:07 runlevel3.target.wants lrwxrwxrwx 1 root root 17 Feb 4 19:06 runlevel4.target -> multi-user.target drwxr-xr-x 2 root root 4096 Jan 25 01:07 runlevel4.target.wants lrwxrwxrwx 1 root root 16 Feb 4 19:06 runlevel5.target -> graphical.target drwxr-xr-x 2 root root 4096 Jan 25 01:07 runlevel5.target.wants lrwxrwxrwx 1 root root 13 Feb 4 19:06 runlevel6.target -> reboot.target -rw-r--r-- 1 root root 360 Oct 28 12:11 sddm.service -rw-r--r-- 1 root root 1063 Jan 25 01:07 serial-getty@.service -rw-r--r-- 1 root root 206 Nov 7 11:48 shadow.service -rw-r--r-- 1 root root 124 Nov 7 11:48 shadow.timer -rw-r--r-- 1 root root 402 Jan 25 01:07 shutdown.target drwxr-xr-x 2 root root 4096 Jan 25 01:07 shutdown.target.wants -rw-r--r-- 1 root root 362 Jan 25 01:07 sigpwr.target -rw-r--r-- 1 root root 420 Jan 25 01:07 sleep.target -rw-r--r-- 1 root root 403 Jan 25 01:07 -.slice -rw-r--r-- 1 root root 409 Jan 25 01:07 slices.target -rw-r--r-- 1 root root 380 Jan 25 01:07 smartcard.target -rw-r--r-- 1 root root 326 Oct 7 11:53 smartd.service -rw-r--r-- 1 root root 445 May 18 2016 smb.service -rw-r--r-- 1 root root 183 Oct 7 19:31 snapper-cleanup.service -rw-r--r-- 1 root root 183 Oct 7 19:31 snapper-cleanup.timer -rw-r--r-- 1 root root 179 Oct 7 19:31 snapper-timeline.service -rw-r--r-- 1 root root 163 Oct 7 19:31 snapper-timeline.timer -rw-r--r-- 1 root root 356 Jan 25 01:07 sockets.target drwxr-xr-x 2 root root 4096 Feb 4 19:06 sockets.target.wants -rw-r--r-- 1 root root 380 Jan 25 01:07 sound.target -rw-r--r-- 1 root root 289 Jan 25 00:51 sshd.service -rw-r--r-- 1 root root 240 Oct 7 10:02 SuSEfirewall2_init.service -rw-r--r-- 1 root root 423 Oct 7 10:02 SuSEfirewall2.service -rw-r--r-- 1 root root 441 Jan 25 01:07 suspend.target -rw-r--r-- 1 root root 353 Jan 25 01:07 swap.target -rw-r--r-- 1 root root 681 Jan 25 01:07 sys-fs-fuse-connections.mount -rw-r--r-- 1 root root 518 Jan 25 01:07 sysinit.target drwxr-xr-x 2 root root 4096 Feb 4 19:06 sysinit.target.wants -rw-r--r-- 1 root root 719 Jan 25 01:07 sys-kernel-config.mount -rw-r--r-- 1 root root 662 Jan 25 01:07 sys-kernel-debug.mount -rw-r--r-- 1 root root 1235 Jan 25 01:07 syslog.socket -rw-r--r-- 1 root root 664 Jan 25 01:07 systemd-ask-password-console.path -rw-r--r-- 1 root root 657 Jan 25 01:07 systemd-ask-password-console.service -rw-r--r-- 1 root root 419 Oct 7 19:20 systemd-ask-password-plymouth.path -rw-r--r-- 1 root root 400 Oct 7 19:20 systemd-ask-password-plymouth.service -rw-r--r-- 1 root root 592 Jan 25 01:07 systemd-ask-password-wall.path -rw-r--r-- 1 root root 689 Jan 25 01:07 systemd-ask-password-wall.service -rw-r--r-- 1 root root 732 Jan 25 01:07 systemd-backlight@.service -rw-r--r-- 1 root root 963 Jan 25 01:07 systemd-binfmt.service -rw-r--r-- 1 root root 654 Jan 25 01:07 systemd-bootchart.service -rw-r--r-- 1 root root 1014 Jan 25 01:07 systemd-bus-proxyd.service -rw-r--r-- 1 root root 409 Jan 25 01:07 systemd-bus-proxyd.socket -rw-r--r-- 1 root root 501 Jan 25 01:07 systemd-exit.service -rw-r--r-- 1 root root 759 Jan 25 01:07 systemd-firstboot.service -rw-r--r-- 1 root root 578 Jan 25 01:07 systemd-fsck-root.service -rw-r--r-- 1 root root 631 Jan 25 01:07 systemd-fsck@.service -rw-r--r-- 1 root root 548 Jan 25 01:07 systemd-halt.service -rw-r--r-- 1 root root 635 Jan 25 01:07 systemd-hibernate-resume@.service -rw-r--r-- 1 root root 505 Jan 25 01:07 systemd-hibernate.service -rw-r--r-- 1 root root 714 Jan 25 01:07 systemd-hostnamed.service -rw-r--r-- 1 root root 786 Jan 25 01:07 systemd-hwdb-update.service -rw-r--r-- 1 root root 523 Jan 25 01:07 systemd-hybrid-sleep.service -rw-r--r-- 1 root root 660 Jan 25 01:07 systemd-importd.service -rw-r--r-- 1 root root 484 Jan 25 01:07 systemd-initctl.service -rw-r--r-- 1 root root 524 Jan 25 01:07 systemd-initctl.socket -rw-r--r-- 1 root root 671 Jan 25 01:07 systemd-journal-catalog-update.service -rw-r--r-- 1 root root 607 Jan 25 01:07 systemd-journald-audit.socket -rw-r--r-- 1 root root 1090 Jan 25 01:07 systemd-journald-dev-log.socket -rw-r--r-- 1 root root 1297 Jan 25 01:07 systemd-journald.service -rw-r--r-- 1 root root 842 Jan 25 01:07 systemd-journald.socket -rw-r--r-- 1 root root 735 Jan 25 01:07 systemd-journal-flush.service -rw-r--r-- 1 root root 561 Jan 25 01:07 systemd-kexec.service -rw-r--r-- 1 root root 695 Jan 25 01:07 systemd-localed.service -rw-r--r-- 1 root root 1130 Jan 25 01:07 systemd-logind.service -rw-r--r-- 1 root root 952 Jan 25 01:07 systemd-machined.service -rw-r--r-- 1 root root 697 Jan 25 01:07 systemd-machine-id-commit.service -rw-r--r-- 1 root root 971 Jan 25 01:07 systemd-modules-load.service -rw-r--r-- 1 root root 1378 Jan 25 01:07 systemd-nspawn@.service -rw-r--r-- 1 root root 557 Jan 25 01:07 systemd-poweroff.service -rw-r--r-- 1 root root 622 Jan 25 01:07 systemd-quotacheck.service -rw-r--r-- 1 root root 725 Jan 25 01:07 systemd-random-seed.service -rw-r--r-- 1 root root 552 Jan 25 01:07 systemd-reboot.service -rw-r--r-- 1 root root 761 Jan 25 01:07 systemd-remount-fs.service -rw-r--r-- 1 root root 700 Jan 25 01:07 systemd-rfkill.service -rw-r--r-- 1 root root 617 Jan 25 01:07 systemd-rfkill.socket -rw-r--r-- 1 root root 501 Jan 25 01:07 systemd-suspend.service -rw-r--r-- 1 root root 653 Jan 25 01:07 systemd-sysctl.service drwxr-xr-x 2 root root 4096 Feb 4 11:54 systemd-sysctl.service.d -rw-r--r-- 1 root root 664 Jan 25 01:07 systemd-sysusers.service -rw-r--r-- 1 root root 659 Jan 25 01:07 systemd-timedated.service -rw-r--r-- 1 root root 1036 Jan 25 01:07 systemd-timesyncd.service -rw-r--r-- 1 root root 602 Jan 25 01:07 systemd-tmpfiles-clean.service -rw-r--r-- 1 root root 450 Jan 25 01:07 systemd-tmpfiles-clean.timer -rw-r--r-- 1 root root 707 Jan 25 01:07 systemd-tmpfiles-setup-dev.service -rw-r--r-- 1 root root 687 Jan 25 01:07 systemd-tmpfiles-setup.service -rw-r--r-- 1 root root 578 Jan 25 01:07 systemd-udevd-control.socket -rw-r--r-- 1 root root 570 Jan 25 01:07 systemd-udevd-kernel.socket -rw-r--r-- 1 root root 864 Jan 25 01:07 systemd-udevd.service -rw-r--r-- 1 root root 233 Jan 25 01:07 systemd-udev-root-symlink.service -rw-r--r-- 1 root root 827 Jan 25 01:07 systemd-udev-settle.service -rw-r--r-- 1 root root 751 Jan 25 01:07 systemd-udev-trigger.service -rw-r--r-- 1 root root 634 Jan 25 01:07 systemd-update-done.service -rw-r--r-- 1 root root 761 Jan 25 01:07 systemd-update-utmp-runlevel.service -rw-r--r-- 1 root root 762 Jan 25 01:07 systemd-update-utmp.service -rw-r--r-- 1 root root 581 Jan 25 01:07 systemd-user-sessions.service -rw-r--r-- 1 root root 617 Jan 25 01:07 systemd-vconsole-setup.service -rw-r--r-- 1 root root 436 Jan 25 01:07 system.slice -rw-r--r-- 1 root root 585 Jan 25 01:07 system-update.target drwxr-xr-x 2 root root 4096 Feb 4 12:00 system-update.target.wants -rw-r--r-- 1 root root 405 Jan 25 01:07 timers.target drwxr-xr-x 2 root root 4096 Feb 4 19:06 timers.target.wants -rw-r--r-- 1 root root 395 Jan 25 01:07 time-sync.target -rw-r--r-- 1 root root 240 Oct 16 2014 tuned.service -rw-r--r-- 1 root root 159 Oct 8 08:42 udisks2.service -rw-r--r-- 1 root root 417 Jan 25 01:07 umount.target -rw-r--r-- 1 root root 451 Oct 28 10:35 upower.service drwxr-xr-x 2 root root 4096 Feb 4 19:06 user@0.service.d -rw-r--r-- 1 root root 514 Jan 25 01:07 user@.service -rw-r--r-- 1 root root 392 Jan 25 01:07 user.slice -rw-r--r-- 1 root root 475 Jan 25 01:07 var-lib-machines.mount -rw-r--r-- 1 root root 154 Oct 28 12:11 var-lib-nfs-rpc_pipefs.mount -rw-r--r-- 1 root root 541 Jan 25 01:07 var-lock.mount -rw-r--r-- 1 root root 536 Jan 25 01:07 var-run.mount -rw-r--r-- 1 root root 313 Jul 21 2016 vpnc@.service -rw-r--r-- 1 root root 167 Oct 7 16:52 wacom-inputattach@.service -rw-r--r-- 1 root root 498 Dec 8 03:17 wickedd-auto4.service -rw-r--r-- 1 root root 496 Dec 8 03:17 wickedd-dhcp4.service -rw-r--r-- 1 root root 496 Dec 8 03:17 wickedd-dhcp6.service -rw-r--r-- 1 root root 482 Dec 8 03:17 wickedd-nanny.service -rw-r--r-- 1 root root 248 Dec 8 03:17 wickedd-pppd@.service -rw-r--r-- 1 root root 646 Dec 8 03:17 wickedd.service -rw-r--r-- 1 root root 577 Dec 8 03:17 wicked.service -rw-r--r-- 1 root root 510 May 18 2016 winbind.service -rw-r--r-- 1 root root 265 Oct 7 18:44 wpa_supplicant.service -rw-r--r-- 1 root root 228 Oct 7 19:17 xinetd.service -rw-r--r-- 1 root root 760 Jan 16 09:25 YaST2-Firstboot.service -rw-r--r-- 1 root root 1651 Jan 16 09:25 YaST2-Second-Stage.service -rw-r--r-- 1 root root 652 Jun 27 2016 ypbind.service and when I did the grep command, this is what I got.... darkstar:/usr/lib/systemd/system # grep run * grep: invalid option -- '.' Usage: grep [OPTION]... PATTERN [FILE]... Try 'grep --help' for more information.

% got, (at least my interpretation of the answers) was that it failed % because there are file names in the directory which had the string % "run" within the filename... Hence the need for the double dashes as

I believe your interpretation is incorrect.

OMG! you know you are probably right! ;-) Looking hard at the listing of the files in that directory, I just now noticed a file named "-.slice" !!! Could that be the bugger that screwed up grep on me? IF SO, then I will still argue and maintain my position that the shell language processing semantics is badly designed because it is resulting in unexpected behaviors. If the leading dash in this file name -.slice got interpreted as an option, to be passed on to grep, after expansion of the * wildcard character (who's expected behavior is to return a list of files) then the semantic design of that expansion has failed. I say that in the sense of it not automatically providing an escape mechanism for preventing interpretation of the dash character, or any other token that has special meaning, in an unintended fashion. I, as a user, should not have to know the details about how to handle special tokens, and whether any files in a directory have such tokens embedded in their names! My expectation, rightfully so, is to expect the * wildcard to return a parsed and interpreted list of file names back to the command that invoked it and for grep or any other utility to interpret that list as nothing more than a list of file names. The ability to define and provide escape character mechanisms, for language processing, is basic computer science! All that is needed is an agreement between the utility and the regular expression processor what characters or strings are to be treated as special tokens and what escape mechanism should be use to prevent unintended interpretations. (As an side comment, whoever came up with the idea to use a file name of "-.slice" needs to have their head examined!) IF NOT, and the file -.slice did not break my intuitive expectations of how this grep command should have worked, then I am back to my original theory that the search for the "run" pattern somehow broke grep because the * wildcard expanded into a list of filenames which included the pattern "run" in their name. Bottom line is, the results of my doing this simple grep command exceeded my ability to easily grok why it failed. The error message is inadequate at helping me to understand what when wrong, especially when the very same command works in other directories just fine. That does implies inconsistent directory or file name or perhaps permissions or ??? some other related effects on the execution of the grep command, but wow, how is a poor user, who does not have a deep understanding of the internals of shell semantics or grep's algorithms suppose to figure this out?

% the first parameter in order to get this grep command to work.. % Please review this thread from the beginning...

I just went back and looked again, and I still don't see any further diagnostic information from you. If you wish an explanation of the cause beyond Linda's excellent suggestion to de-argument-ify the tokens on the command line, you should show us with what you're working.

I love your term - de-argument-ify!!! I GOTTA figure out how to use it in some of my other conversations! I wonder how my wife will react if I use it on her! LOL Thanks so much for your help.... Marc... -- "The Truth is out there" - Spooky -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Marc, et al -- ...and then Marc Chamberlin said... % % On 03/16/2017 07:57 PM, David T-G wrote: % > % >Did you ever provide a listing of the contents of your example directory? % >I've been watching this thread, and if you sent it I must have missed it. ... % >I'm very interested in what that period-space appears to be and how it % >played into your command line, not least because % > % > * % > % >does not pick up "hidden" files (those starting with a period). % % David - I can certainly provide a listing for you, but I suspect you % could probably try this on your own systems... I had cd'd to Alas, no: davidtg@u17383850:~> cat /etc/SuSE-release openSUSE 12.1 (x86_64) VERSION = 12.1 CODENAME = Asparagus davidtg@u17383850:~> cd /usr/lib/systemd/system bash: cd: /usr/lib/systemd/system: No such file or directory % /usr/lib/systemd/system and was curious as to how other services % were initializing pid files and directories in the temporary /run % and /var/run directories. So I thought I would do a grep for the % string "run" to see if I could get a clue.. (I am setting up Seems like an easy thing :-) % Bacula on my systems and needed to create the .service files for it, % and yes I have now figured out how to initialize directories and % files in /run.) % % So here is a full listing of what is in my /usr/lib/systemd/system % directory (sorry there is a lot of files there, so this is going % to be long and noisy, but I want to be thorough and not leave any % necessary info out...) Thanks! That certainly helps. As Andreas saw, yes, there is a fun file there. And I bet you aren't using LANG=C or LC_ALL=C, too, since that is sorted so poorly, but it's still findable. ... % > % >I believe your interpretation is incorrect. % OMG! you know you are probably right! ;-) Looking hard at the Don't worry; stranger things have happened! :-) ... % Bottom line is, the results of my doing this simple grep command % exceeded my ability to easily grok why it failed. The error message % is inadequate at helping me to understand what when wrong, That's true, and that's unfortunate. I bet that AIX, which breaks all conventions to look like a mainframe OS, would have done a better job of explaining. Linux, like UNIX, isn't unfriendly but simply very choosy about its friends :-) ... % >diagnostic information from you. If you wish an explanation of the cause % >beyond Linda's excellent suggestion to de-argument-ify the tokens on the % >command line, you should show us with what you're working. % > % I love your term - de-argument-ify!!! I GOTTA figure out how to use % it in some of my other conversations! I wonder how my wife will % react if I use it on her! LOL Glad to help! I think that we've managed to de-argument-ify this whole thread, too :-) % % Thanks so much for your help.... Marc... HAND :-D -- David T-G See http://justpickone.org/davidtg/email/ See http://justpickone.org/davidtg/tofu.txt -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 16/03/17 23:56, David Haller wrote:

Ooooch mennooo! That takes out all the fun!

Hasn't it been the lore, that if you've not once accidentally run 'rm -rf /' or at least 'rm -rf ~', you're no UNIX/Linux guy?

:-) I remember having to recover one of our user's home directory once. COPY <SYS181>DEBBIE>FILE <RAB191>DEBBIE iirc. The system came back with "you are about to overwrite a directory with a file. Continue?", and, not thinking or rather thinking "but of course I want to copy that file into my home directory" she hit "yes". One home directory deleted. Unlike on nix, the Pr1mos COPY command always made an exact copy of the first argument, called the second argument. And (enforced by the OS), the command expansion prompted by default if it thought the command was dangerous eg as here overwriting a directory. She should have had second thoughts at the mere existence of the warning. I still think the Pr1mos shell was much better than nix, but hey ho... Cheers, Wol -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Hello, On Fri, 17 Mar 2017, Carlos E. R. wrote:

On 2017-03-17 00:56, David Haller wrote:

...

Or at least: you deleted some files via a tyop, and learned from it. ^^^^ BTW@the other David that was an intentional typo ;)

...

Well, I hope that after many years, that I've learned to enter a Ctrl-c unless I'm _REALLY_ sure (triple-, quadruple-checked) the commandline I've just entered.. 'dd if=/dev/zero of=/dev/sdNOSUCHDEV' anyone? where NOSUCHDEV actually is something like 'c' or such ;)

Enter a ctrl-c? in the command line? How?

Hold ctrl and hit the c-key? ;) Sorry, I was somewhat misleading there: I meant _when I'm typing up such a command_, and double-, triple-, quaduple check it _*BEFORE*_ hitting enter. And if I'm not 100% sure, I hit Ctrl-C to abort that typed-but-not-called cmdline, instead of doing anything else. E.g. $ dd if=/dev/zero of=/tmp/t.img bs=1M count=1^C $ echo $? 130 Oh, and of course you can enter a literal ctrl-c on the command-line, just as any other char, by hitting ctrl-v before: $ echo '^C' | od -tx1z 0000000 03 0a >..< 0000002 That was entered as: echo 'ctrl-v ctrl-c' | od -tx1z HTH, -dnh -- Any smoothly functioning technology will be indistinguishable from a rigged demo. -- Isaac Asimov -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Hello, On Fri, 17 Mar 2017, Marc Chamberlin wrote:

Bottom line is, the results of my doing this simple grep command exceeded my ability to easily grok why it failed. The error message is inadequate at helping me to understand what when wrong, especially when the very same command works in other directories just fine. That does implies inconsistent directory or file name or perhaps permissions or ??? some other related effects on the execution of the grep command, but wow, how is a poor user, who does not have a deep understanding of the internals of shell semantics or grep's algorithms suppose to figure this out?

Neither actually. Just some very basic facts about the shell and globbing. If you don't want to learn those, try using 'mc'. And actually, it _is_ rather simple: The shell expands the '*' and replaces the '*' with the result of the expansion. If that result happens to contain a string(!) (argument) that is an option for the command called, then, the command will take that string/argument as an option (unless a preceding argument was the special option '--' and the command has that '--' option). Again: use 'set -x' liberally if you don't understand something the shell is doing. After setting 'x' via 'set -x' each command executed is output before execution, prefixed with '+ '. E.g.: $ touch a b $ ls * a b $ touch ./-l $ ls * -rw-r--r-- 1 dh dh 0 Mar 18 16:19 a -rw-r--r-- 1 dh dh 0 Mar 18 16:19 b $ set -x $ ls * + ls -l a b -rw-r--r-- 1 dh dh 0 Mar 18 16:19 a -rw-r--r-- 1 dh dh 0 Mar 18 16:19 b $ rm ./-l + rm ./-l $ ls * + ls a b a b I could go into even further details (strace -eprocess ... ;), but the above should suffice. Once you've understood this, that the shell is just expanding and passing on the result, the behaviour of grep in this case becomes clear, as you've called it with the option '-.slice'. Again: Your $ grep run * in that dir (and not in other dirs) expanded to $ grep run ... -.slice ... and grep took the '-.' as an option. And to avoid that, use either '--' or './' or both, i.e. any of: $ grep run -- * $ grep run ./* $ grep run -- ./* Again: I recommend reading up on basic shell behaviour, esp. regarding "globbing" ;) Oh, and yes: with most GNU and other programs, options may appear anywhere on the command-line, which exactly is a feature of getopt and other option-parsing functions/libs that "bit" you in this case, so, a command: $ cmd foo -a b -c is the same as $ cmd -a -c -- foo b The latter is actually what 'getopt(3)' makes out of the former, IIRC (I'd have to check with strace and can't bother now). And having the '--' option is a consequence of this flexibility of allowing options anywhere instead of just between the command and the first non-option. Compare 'find' for a rather strict commandline- parsing. But there is an upside: you could touch a file ./-i in some directories to avoid an accidental 'rm * ~' instead of 'rm *~' ;) I don't recommend this though, better learn to be strict in "think (twice) before pressing enter"... Actually, after almost 20 years of using Linux, I still routinely use $ ls ... or $ echo rm ... before calling $ rm ... Just to be sure I've got the globbing and other stuff right. Remember: the shell and called commands do what you tell them to. It is _your_ responsibility what you call. Oh, but feel free to ask, once you're reading up on it and have trouble understanding this or that. HTH, -dnh -- Jeder hat das Recht auf seine eigene Meinung, aber er hat keinen Anspruch darauf, dass andere sie teilen. -- Manfred Rommel -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 2017-03-18 17:07, David Haller wrote:

Hello,

On Sat, 18 Mar 2017, Carlos E. R. wrote:

...

On 2017-03-17 08:34, Andreas Mahel wrote:

...

The issue in the systemd unit directory is different: in that folder exists a file named "-.slice".

And the file name starting with a dash will make grep interpret this as a set of command line options, where it fails at the first one already, the dot.

Grep could deduce that, as that "-.slice" is an apparent option in the middle of some files, that it is an error, and report it as such.

Albeit, yes, but that would be some heuristic doomed to fail in the most inconvenient way at some point... Better stay with what most other commands do and be consistent.

Consider:

$ grep bla foo*

you remember, fsck, I need just a fixed-string search

$ grep bla foo* -F

you remember you need to search bar* too

$ grep bla foo* -F bar*

But then, suppose: grep bla *foo -F bar* And there is one file in the directory named "-foo", you could have a problem.

With your proposition, this would not be possible. Yes, it's stupid. But not quite unrealistic, if your wrangling long cmd-lines and know the GNU toolchest / getopt.

My idea is to just take the chance to enlighten users when an error like that is detected. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" (Minas Tirith))

On 18/03/17 17:31, Carlos E. R. wrote:

...

With your proposition, this would not be possible. Yes, it's stupid.

...

But not quite unrealistic, if your wrangling long cmd-lines and know the GNU toolchest / getopt.

My idea is to just take the chance to enlighten users when an error like that is detected.

Dunno where I came across it, but good interface technique says "confusing interface design is a bug". Okay, I know I know, you can't always do anything about it, but think back to the days when guis first came out. People used to character interfaces used "return" to jump to the next input field. Then guis re-purposed it to mean "form finished", and introduced "tab" to jump to the next field. That STILL catches me out, and how long is it since I've used CUI forms? Ten years? (they're probably still out there, you know ... :-) Or click-through warnings? Because so many of them are meaningless, users miss the important ones. Okay, you might not be able to do too much about it here, but how many naive users would think of looking in the SHELL manual, to find out why the GREP command wasn't working? The problem is that many of us are *not* power users, using a system that *was* *designed* for power users. (I swear blue murder at MS Word for the opposite reason - designed for idiots and forced on power users :-) Cheers, Wol -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 3/16/2017 11:47 PM, Andrei Borzenkov wrote:

16.03.2017 22:13, Brian K. White пишет:

...

And the windows cmd command line parsing is absolutely terrible example. You may not understand or like the rules that all of the unix shells follow, but the at least have rules, which they follow, and which are consistent and predictable and allow you to express anything you need.

Except

a) there are no rules how each individual command will interpret mix of "option" and "non-option" arguments.

b) heck, there is even no notion of what "option" is - each command is free to define what it treats as "option" and what it treats as "argument".

So no, do not start me on Unix consistency. While shell expansion may be consistent, what commands do with result of shell expansion is not.

What I said was that the bourne shell is a well defined and yes, well designed interface. Feel free to "fix" it if you find it complicated. It's only been honed by legitimate geniuses millions of users for 40 years, literally 40, 1977 to 2017, but hey you probably can clean it all up and make something that is powerful enough to express all problems, yet be simple enough for my mom to use it without ever suffering any unexpected action. Until then, you have no business talking about poor design. You sound like a kid who never learned how to drive a manual transmission claiming that they are a poor design because he never figured it out and doesn't like how he tried to jump in the car and go, but instead it just stalled. Stupid car, poor design. Of course every program is free to parse it's command line arguments however it wishes. Just like it's free to do pretty mush anything else it wishes, which is totally different from every other program. One program sends faxes, another manipulates the bluetooth device, another displays icons on a desktop. A utility like rsync has pretty different requirements of it's commandline than cat or echo. What they do with their commandline is no different than what they do with their memory allocation or the open file descriptors. This is just a completely idiotic idea to even try to float. Similarly, trying to have a program detect that "this looks like an option but it's in the middle of a bunch of filenames" and treat that like an error is idiotic. That is a perfectly useful option which exists for a reason, not by some oversight of those stupid blundering shell or getopt authors. It's intentional to be able to, for example, build a command line from a loop, which changes options as the loop goes along. opt file file opt opt file opt file... -- bkw -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 3/20/2017 3:32 PM, Carlos E. R. wrote:

On 2017-03-20 18:46, Brian K. White wrote:

...

Similarly, trying to have a program detect that "this looks like an option but it's in the middle of a bunch of filenames" and treat that like an error is idiotic. That is a perfectly useful option which exists for a reason, not by some oversight of those stupid blundering shell or getopt authors. It's intentional to be able to, for example, build a command line from a loop, which changes options as the loop goes along. opt file file opt opt file opt file...

No, I can not agree here.

It is impossible for the parser to differentiate between an option in the middle of the stream of file names, or a file that starts with a dash. it is ambiguous at best.

You neither agreed nor disagreed. You said something that is only true sometimes, and not true other times, and has no ultimate meaning and does not invalidate the statement that it's intentional and useful that you can build commandlines for most programs in any order you like. Filenames ARE options, and the parser absolutely does differentiate strings according to whatever rules a given program has defined. Those rules will necessarily be different for different programs, as different programs do different kinds jobs. And there are more kinds of arguments than just flags and filenames. There are urls and really any number of other special purpose syntaxes for example the difference between user@host:module and user@host::module for rsync. And there is no option for disagreeing that it's intentional and useful to be able to construct commandlines for most programs in arbitrary order. It simply is. It's like trying to argue that it's not useful to be able to specify either an absolute path or a relative path. If a filename happens to look exactly the same as some other option that happens to have some special meaning to the given program, it is up to the user to differentiate those one way or another. For example, simply specifying paths as "./* instead of "*" usually takes care of all such problems. And that example is really just akin to simply speaking with less ambiguity in general. If I tell you to pick up all the rocks, the ambiguity is my fault for not specifying which kind rocks from what defined area, not the English languages fault for allowing me to speak an ambiguous statement. -- bkw -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org