On 18.07.14 15:54, Brian May wrote:
> On Unix, it is the shell that is responsible for splitting the arguments,
> and it gets confused easily (i.e. it can't always tell exactly what is
> required). Last I checked, this is different on Windows.
Is that really where the confusion lies? There seems to be some
rationalising and exporting of internalised beliefs on this thread.
Every *nix shell CLI has a well defined grammar. The most fundamental
rule common to all the grammars is that the space character is the field
separator. (Please feel free to add supplementary names, such as "token"
or whatever, but the examples shown so far confirm precisely what _is_
being separated - nonspace text.)
The CLI provides quoting, to postpone globbing, and for the occasions
when a space-separated list needs to be presented as a single argument.
Within quotes, the matching quote temporarily becomes the field
terminator, suppressing recognition of the field separator until then.
This can be abused to present a list of words as a filename, and once
past the CLI, the spaces have lost significance, so the bodge works.
That does not make it good unix practice, as confirmed by the fact that
those who come after must also take extra steps to fool the CLI every
time they encounter such a bodge.
And with a backslash, the field separator can be re-identified as not a
field separator. Let us fully understand that when we present to the
CLI, a filename such as some\ file, it is not a filename with a space,
but rather a string containing a '\' followed by an unidentified
character. It can more concisely be substituted with some_file.
Jamming filenames with spaces through the CLI is a fraught process,
liable to surprises, especially amongst the careless. If that is
doubted, just consider:
# rm -rf / tmp/*
where the spacebar has been accidentally whacked an extra time. Quite a
powerful reminder that there are no spaces in filenames is provided.
The CLI _knows_ that there are no spaces in filenames. You may trick it
mostly, but eventually you'll be reminded. I have not examined in detail
precisely why spaces in filenames caused "make" to fail last night, as
mentioned in my upthread post, but it confirms that the traditional *nix
file naming convention still has its benefits, even after the nearly
three decades I've used it.
OK, if interworking with that other OS, e.g. via NFS or samba, then all
bets are off, and one survives as best one can. I've only ever gone as
far as serving read-only files, so safe naming was assured.
ISTM that the problem would go away if NFS and samba provided filename
translation between OSs.
Erik
--
Reality is that which, when you stop believing in it, doesn't go away.
- Philip K. Dick
_______________________________________________
luv-main mailing list
[email protected]
http://lists.luv.asn.au/listinfo/luv-main
