| Sysop: | Amessyroom |
|---|---|
| Location: | Fayetteville, NC |
| Users: | 43 |
| Nodes: | 6 (0 / 6) |
| Uptime: | 94:22:25 |
| Calls: | 290 |
| Calls today: | 1 |
| Files: | 904 |
| Messages: | 76,378 |
(I’ll be disappointed in extreme cases of course, e.g. filesystems that permit ‘/’ in filenames, but the scale of the problem can be minimized.)
I think the thing that makes it hard is not the spaces as such, but the tooling that makes it inconvenient to handle them, which primarily means Bourne shell parsing rules. The problem basically ceases to exist once you’re outside the shell ecosystem.
The rest of Unix has evolved substantially since the 1970s but shell is
still stuck in this particular trap. It’s like we’re still making making arrowheads out of flint but everything else from steel.
If you avoid newlines in filenames, Posix shells can cope with anything
else if you set “IFS=$'\n'”.
I wrote:
If you avoid newlines in filenames, Posix shells can cope with anything
else if you set “IFS=$'\n'”.
Sorry, no, it looks like the “$'...'” syntax for string literals is not from Posix, it’s a Bash-ism.
I think it’s still possible to assign a newline to $IFS, it just takes a bit more work.
Ralf Fassel <ralfixx@gmx.de> writes:
* Richard Kettlewell <invalid@invalid.invalid>
| Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
| > [...] For example, I might type something like:
| >
| > for file in * ; do cp -p $file $file.bak ; done
|
| That’s the heart of the matter. Field splitting happens after
| parameter expansion.
Only sometimes it doesn't :-)
$ foo="foo bar"
$ bar=$foo
No problem with the space in the expanded value here!
$ echo $bar
foo bar
but of course:
ls $bar
ls: cannot access 'foo': No such file or directory
ls: cannot access 'bar': No such file or directory
Fair point. “Field splitting happens after parameter expansion, except
when it doesn’t”.
I wrote:
If you avoid newlines in filenames, Posix shells can cope with anything
else if you set “IFS=$'\n'”.
Sorry, no, it looks like the “$'...'” syntax for string literals is not from Posix, it’s a Bash-ism.
I wrote:
If you avoid newlines in filenames, Posix shells can cope with
anything else if you set “IFS=$'\n'”.
Sorry, no, it looks like the “$'...'” syntax for string literals
is not from Posix, it’s a Bash-ism.
I think it’s still possible to assign a newline to $IFS, it just
takes a bit more work.
On Sat, 31 Aug 2024 09:27:44 +0100, Richard Kettlewell wrote:
I think the thing that makes it hard is not the spaces as such,
but the tooling that makes it inconvenient to handle them,
which primarily means Bourne shell parsing rules. The problem
basically ceases to exist once you’re outside the shell
ecosystem.
The rest of Unix has evolved substantially since the 1970s but
shell is still stuck in this particular trap. It’s like we’re
still making making arrowheads out of flint but everything else
from steel.
If you avoid newlines in filenames, Posix shells can cope with
anything else if you set “IFS=$'\n'”.
If you insist on wanting to accept those as well, then I don’t
think Posix is enough, but Bash does have facilities that help
you cope.
I wrote:
If you avoid newlines in filenames, Posix shells can cope with
anything else if you set “IFS=$'\n'”.
Sorry, no, it looks like the “$'...'” syntax for string literals
is not from Posix, it’s a Bash-ism.
* Richard Kettlewell <invalid@invalid.invalid>
| Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
| > [...] For example, I might type something like:
| >
| > for file in * ; do cp -p $file $file.bak ; done
| That’s the heart of the matter. Field splitting happens after parameter
| expansion.
Only sometimes it doesn't :-)
$ foo="foo bar"
$ bar=$foo
No problem with the space in the expanded value here!
$ echo $bar
foo bar
but of course:
ls $bar
ls: cannot access 'foo': No such file or directory
ls: cannot access 'bar': No such file or directory
It's documented in bash(1):
PARAMETERS
[...]
A variable may be assigned to by a statement of the form
name=[value]
[...] Word splitting is not performed, with the exception of
"$@" as explained below under Special Parameters.
but I find it confusing nevertheless.
R'
I wrote:
If you avoid newlines in filenames, Posix shells can cope with anything
else if you set “IFS=$'\n'”.
Sorry, no, it looks like the “$'...'” syntax for string literals is not from Posix, it’s a Bash-ism.
On 9/1/2024 3:03 AM, Lawrence D'Oliveiro wrote:
Sorry, no, it looks like the “$'...'” syntax for string literals is not >> from Posix, it’s a Bash-ism.
Actually, dollar quotes were added to POSIX as of SUS Issue 8:
For example, I might type something like:
for file in * ; do cp -p $file $file.bak ; done
On Tue, 03 Sep 2024 15:16:36 -0700, Keith Thompson wrote:
For example, I might type something like:
for file in * ; do cp -p $file $file.bak ; done
It’s quite easy to fix that to work with spaces in file names. How long >have you been working with *nix shells?
Lawrence D'Oliveiro <ldo@nz.invalid> writes:
On Tue, 03 Sep 2024 15:16:36 -0700, Keith Thompson wrote:
For example, I might type something like:
for file in * ; do cp -p $file $file.bak ; done
It’s quite easy to fix that to work with spaces in file names.
I wouldn't call it "quite easy".
The make utility has no support for paths with spaces.
Looks like you're right.
John Ames <commodorejohn@gmail.com> writes:
On Tue, 3 Sep 2024 20:11:28 -0000 (UTC)
Kaz Kylheku <643-408-1753@kylheku.com> wrote:
Because it is based on a strawman interpretation of the "no spaces"
rule. That strawman interpretation is that there are no other rules
used in combination with the "no spaces" rule, and thus that any
ridiculous name is fine, just as long as it doesn't contain spaces.
And so, look how unreadable is this 100 character name in CamelCase!
Q.E.D. no spaces is a bad recommendation!
Well, there were no other factors *presented* alongside the blanket
statement that spaces in filenames are unnecessary, so it would appear
on the face of it to be an accurate assessment of the claim being made,
which wasn't in a post of yours to begin with.
And I'd still like to know who died and made whom king where filenames
and spaces therein are concrned.
There is no official "rule" about spaces in filenames, though I can
imagine easily imagine that some organizations and projects have
rules forbidding them. A couple of data points: The gcc git repo
contains 137394 files and none of them have spaces in their names.
The Linux kernel git repo contains 85803 files, and exactly one has
spaces in its name.
Spaces in file names are likely not to be an issue if you interact
with the filesystem via a GUI like Windows Explorer *or* if you use
a scripting language like Perl or Python that requires strings used
as filenames to be enclosed in quotation marks. In those contexts,
space is just another character.
Lawrence D'Oliveiro <ldo@nz.invalid> writes:
How long have you been working with *nix shells?
A long time. [...]
Lawrence D'Oliveiro <ldo@nz.invalid> writes:
I have some Makefiles with spaces in the dependency names, of the form:
target\ name\ with\ space : source\ name\ with\ space
I'd be interested in knowing how you do that.
$ cat Makefile foo\ bar: foo\ bar.c
$ make cc foo bar.c -o foo bar
cc: fatal error: input file ‘foo’ is the same as output file
compilation terminated.
Second attempt:
IFS='\n' ; for file in * ; do cp -p $file $file.bak ; done
but that leaves IFS set to its new value in my interactive shell.
Lawrence D'Oliveiro <ldo@nz.invalid> writes:
Next step: what if you wanted to handle newlines in file names as well?
Either `find ... -print0 | xargs -0 ...` or a quick Perl script.
Lawrence D'Oliveiro <ldo@nz.invalid> writes:
The Makefiles in question are not using the default build rules for C
code: they are building other things, with explicit use of the "$<" and
"$@" variable substitutions.
I'd still be interested in seeing an example.
Lawrence D'Oliveiro <ldo@nz.invalid> writes:[I tried to restore the newlines at the appropriate places here, I hope
On Tue, 03 Sep 2024 17:19:17 -0700, Keith Thompson wrote:
Lawrence D'Oliveiro <ldo@nz.invalid> writes:
I have some Makefiles with spaces in the dependency names, of the form: >>>>
target\ name\ with\ space : source\ name\ with\ space
I'd be interested in knowing how you do that.
$ cat Makefile
foo\ bar: foo\ bar.c
$ make
cc foo bar.c -o foo bar
cc: fatal error: input file ‘foo’ is the same as output file
compilation terminated.
The Makefiles in question are not using the default build rules for C
code: they are building other things, with explicit use of the "$<" and
"$@" variable substitutions.
I'd still be interested in seeing an example. In a quick experiment,
I wasn't able to get GNU Make to recognize the existence of a file named
"foo bar".
Ralf Fassel <ralfixx@gmx.de> writes:
* Lawrence D'Oliveiro <ldo@nz.invalid>
| On Tue, 03 Sep 2024 16:10:42 -0700, Keith Thompson wrote:
| > Lawrence D'Oliveiro <ldo@nz.invalid> writes:
| >>
| >> On Tue, 03 Sep 2024 15:16:36 -0700, Keith Thompson wrote:
| >>>
| >>> For example, I might type something like:
| >>>
| >>> for file in * ; do cp -p $file $file.bak ; done
| >>
| >> It’s quite easy to fix that to work with spaces in file names.
| >
| > I wouldn't call it "quite easy".
| As easy as this, in Bash at least:
| IFS=$'\n'
Forgive my ignorance, but what is wrong with
for file in * ; do cp -p "$file" "$file.bak" ; done
? Works for both spaces and newlines in file names... (at least with
bash and ksh).
You're absolutely right. I'm not sure how I missed that. (I was
thinking that * just expands to a string, but that's obviously not the
case.)
D'oh!
Lawrence D'Oliveiro <ldo@nz.invalid> writes:
On Tue, 03 Sep 2024 16:38:06 -0700, Keith Thompson wrote:
The make utility has no support for paths with spaces.
Looks like you're right.
I have some Makefiles with spaces in the dependency names, of the form:
target\ name\ with\ space : source\ name\ with\ space
I'd be interested in knowing how you do that.
$ cat Makefile
foo\ bar: foo\ bar.c
$ make
cc foo bar.c -o foo bar
cc: fatal error: input file ‘foo’ is the same as output file
compilation terminated.
make: *** [<builtin>: foo bar] Error 1
On Tue, 3 Sep 2024 23:15:46 -0000 (UTC)
Kaz Kylheku <643-408-1753@kylheku.com> wrote:
The make utility has no support for paths with spaces.
Use of make is a great repellant against spaces in names.
If a make variable contains spaces, there is no way to quote it within
make. There is no way to express a prerequisite or target name with
spaces. GNU Make text processing constructs like $(foreach ...)
don't deal with spaces; there is no way for them to identify items
that contain spaces.
If the make utility has no provisions for coping with a subset of legal >filenames, that would seem to be a deficiency in make.
Spaces in file names are likely not to be an issue if you interact
with the filesystem via a GUI like Windows Explorer *or* if you use
a scripting language like Perl or Python that requires strings used
as filenames to be enclosed in quotation marks. In those contexts,
space is just another character.
It can be a real issue if you're interacting via shell commands.
If I happen to know that none of the files I'm working with have
spaces (or other problematic characters) in their names, a lot of
things become easier -- but risky if there's a funny character I'm
not aware of. For example, I might type something like:
for file in * ; do cp -p $file $file.bak ; done
It would be ideal, I suppose, if interactive shells dealt better with
spaces in file names, but I'm not sure how that could be achieved. In current shells, removing two files named "foo" and "bar" is easy, and removing a single file named "foo bar" requires some extra effort. I
find that to be a good tradeoff.
* Richard Kettlewell <invalid@invalid.invalid>
| Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
| > [...] For example, I might type something like:
| >
| > for file in * ; do cp -p $file $file.bak ; done
|
| That’s the heart of the matter. Field splitting happens after
| parameter expansion.
Only sometimes it doesn't :-)
$ foo="foo bar"
$ bar=$foo
No problem with the space in the expanded value here!
$ echo $bar
foo bar
but of course:
ls $bar
ls: cannot access 'foo': No such file or directory
ls: cannot access 'bar': No such file or directory
Two comments about spaces in filenames (and Windows vs. Unix):
1) Windows is actually quite a bit more restrictive about characters in
filenames than Unix. Which is a good thing. I've always thought
the "anything other than NUL and /" in Unix was a bad thing and
encouraged all manner of bad/malicious outcomes. Yet, there are
people (and I use the term loosely) who think otherwise.
2) Spaces in filenames are pretty much a necessity from the end-user
POV (but see below). Yes, it makes things hard for us on the admin
side of the game.
2) Spaces in filenames are pretty much a necessity from the end-user
POV (but see below). Yes, it makes things hard for us on the admin
side of the game.
I think the thing that makes it hard is not the spaces as such, but the >tooling that makes it inconvenient to handle them, which primarily means >Bourne shell parsing rules. The problem basically ceases to exist once >you’re outside the shell ecosystem.
The rest of Unix has evolved substantially since the 1970s but shell is
still stuck in this particular trap. It’s like we’re still making making >arrowheads out of flint but everything else from steel.