On 2017-03-17 09:21, Marc Chamberlin wrote:
On 03/16/2017 07:57 PM, David T-G wrote:
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 403 Jan 25 01:07 -.slice
...
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?
Yes.
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!)
Well, yes, I think it is an error in design, but others will say that it is a characteristic of Unix and thus of Linux and get mad at me (LOL). It is not a problem of grep. Nothing that can be done in that respect, except be aware of it and replace the command line with: grep run -- * The "--" tells the command that the next strings should be interpreted as files. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" (Minas Tirith))