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