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.

On Wed, 4 Sep 2024 08:41:03 -0700
John Ames <commodorejohn@gmail.com> boringly babbled:
>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.

Given 99.99% of make use cases are to build binaries from source code and
no sane person would put spaces in the filenames of either, I doubt the
developers of make or its users could care less.

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
> 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

That’s the heart of the matter. Field splitting happens after parameter
expansion. The languages that don’t have trouble with spaces in
filenames[1] don’t do it that way. I suspect if some different design
decisions had been made long ago, nobody would be inferring from the
difficulties shell scripts have handling strings with spaces in that
they were unnecessary or even forbidden in filenames.

[1] or any other kind of string. Let’s not get tunnel vision about
filenames: shell has trouble with spaces in other contexts too.

Tcl is the most instructive example: it has a similar word-base
structure to shell, but largely without getting into the same tangles
over spaces.

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

Agreed. I note that tab completion normally adds any quotes needed,
which deals with most of the issues in interactive mode, for me.

As well as the above observations about shell syntax we could also
wonder whether it was ever really necessary to use the same syntax both
for interactive file management and a programming language.

--
https://www.greenend.org.uk/rjk/

On Wed, 4 Sep 2024 13:17:48 -0000 (UTC), Lew Pitcher wrote:

> The "--" option is just that, an option coded into the argument parser
> of the program being invoked. Many programs /do not/ recognize "--" as
> an "end of flags" argument, so the effectiveness of "--" is unreliable.

All the good ones do. This is why getopt(3) with POSIXLY_CORRECT stops
looking for options as soon as a nonoption argument is encountered.

Remember also that arguments need not necessarily be file names, so
prefixing them all with “./” willy-nilly may not produce the right result
anyway.

On 2024-09-04, Lew Pitcher <lew.pitcher@digitalfreehold.ca> wrote:
> On Wed, 04 Sep 2024 13:04:07 +0000, Kenny McCormack wrote:
>
>> In article <vb9k2l$3r705$1@dont-email.me>,
>> Nuno Silva <nunojsilva@invalid.invalid> wrote:
>> ...
>>>> D'oh!
>>>
>>>(Along with these quotes, I'd add ./ before $file.)
>>
>> Or, more simply, just put -- after the -p.
>>
>> This is an often overlooked aspect of shell programing. You should always
>> use "--". The "shellcheck" program will tell you this, if you let it.
>
> The "--" option is just that, an option coded into the argument parser of
> the program being invoked. Many programs /do not/ recognize "--" as an
> "end of flags" argument, so the effectiveness of "--" is unreliable.
>
> OTOH, if you specify a fully qualified pathname, (or, at least, a qualified
> relative pathname), you can assure yourself that the file path provided
> to the program /will not/ start with the '-' that indicates a program flag.
>
> Note that all this is /convention/ and not /requirement/. There are situations
> in which /none/ of the above applies, as
> a) the program interprets it's arguments by /position/, or
> b) the program doesn't use the '-' to introduce flag arguments, or
> c) the program doesn't take filenames as arguments, or
> d) some other conditions that I'm too lazy to enumerate

d) it's a goddamned GNU program that continues to take options
after non-option arguments!

$ ls . -ld
drwxr-xr-x 67 kaz kaz 36864 Sep 3 15:59 .

.... unless -- is specified to signal the end of options.

$ ls -ld -- . -ld
ls: cannot access '-ld': No such file or directory
drwxr-xr-x 67 kaz kaz 36864 Sep 3 15:59 .

So unfortunately although starting an argument with ./ will
ensure that it's not treated as an option, it doesn't mean
it will be treated as the first non-option argument after
which there are no more option arguments.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

* 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'

On Thu, 05 Sep 2024 02:29:49 +0000, Kaz Kylheku wrote:

> On 2024-09-04, Lew Pitcher <lew.pitcher@digitalfreehold.ca> wrote:
>> On Wed, 04 Sep 2024 13:04:07 +0000, Kenny McCormack wrote:
>>
>>> In article <vb9k2l$3r705$1@dont-email.me>,
>>> Nuno Silva <nunojsilva@invalid.invalid> wrote:
>>> ...
>>>>> D'oh!
>>>>
>>>>(Along with these quotes, I'd add ./ before $file.)
>>>
>>> Or, more simply, just put -- after the -p.
>>>
>>> This is an often overlooked aspect of shell programing. You should always
>>> use "--". The "shellcheck" program will tell you this, if you let it.
>>
>> The "--" option is just that, an option coded into the argument parser of
>> the program being invoked. Many programs /do not/ recognize "--" as an
>> "end of flags" argument, so the effectiveness of "--" is unreliable.
>>
>> OTOH, if you specify a fully qualified pathname, (or, at least, a qualified
>> relative pathname), you can assure yourself that the file path provided
>> to the program /will not/ start with the '-' that indicates a program flag.
>>
>> Note that all this is /convention/ and not /requirement/. There are situations
>> in which /none/ of the above applies, as
>> a) the program interprets it's arguments by /position/, or
>> b) the program doesn't use the '-' to introduce flag arguments, or
>> c) the program doesn't take filenames as arguments, or
>> d) some other conditions that I'm too lazy to enumerate
>
> d) it's a goddamned GNU program that continues to take options
> after non-option arguments!
>
> $ ls . -ld
> drwxr-xr-x 67 kaz kaz 36864 Sep 3 15:59 .
>
> ... unless -- is specified to signal the end of options.
>
> $ ls -ld -- . -ld
> ls: cannot access '-ld': No such file or directory
> drwxr-xr-x 67 kaz kaz 36864 Sep 3 15:59 .
>
> So unfortunately although starting an argument with ./ will
> ensure that it's not treated as an option, it doesn't mean
> it will be treated as the first non-option argument after
> which there are no more option arguments.

That seems to be a symptom of the use of the GNU variant of
the POSIX getopt(3) function.
"By default, [GNU] getopt() permutes the contents of argv as it scans, so that
eventually all the nonoptions are at the end. Two other modes are also
implemented. If the first character of optstring is '+' or the envi-
ronment variable POSIXLY_CORRECT is set, then option processing stops
as soon as a nonoption argument is encountered."

The "workaround" seems to be to set the POSIXLY_CORRECT envvar as part of
your standard environment.

--
Lew Pitcher
"In Skills We Trust"

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

--
https://www.greenend.org.uk/rjk/

Richard Kettlewell <invalid@invalid.invalid> wrote at 17:21 this Thursday (GMT):
> 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”.

Actually, echo is special since it just prints every argument it's
given.. both of these commands are working as expected with splitting:

$ echo some text

some text

$ ls some text

ls: cannot access 'some': No such file or directory
ls: cannot access 'text': No such file or directory
--
user <candycane> is generated from /dev/urandom

In article <slrnvdp692.1s5hi.candycanearter07@candydeb.host.invalid>,
candycanearter07 <candycanearter07@candycanearter07.nomail.afraid> wrote:
....
>>> 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 doesnt.
>
>
>Actually, echo is special since it just prints every argument it's
>given.. both of these commands are working as expected with splitting:
>
> $ echo some text
>
> some text
>
> $ ls some text
>
> ls: cannot access 'some': No such file or directory
> ls: cannot access 'text': No such file or directory

The point is still valid, even if the demonstration wasn't quite on-point.

When faced with the problem of needing to display a variable in shell, but
needing to know whether or not it is a single string or multiple strings, a
useful trick is to use "printf" like this:

$ set -- this is "a test of" something
$ printf "%s\n" "$@"

Then you would know for sure that in the example above, the variable "foo"
really did have the value "foo bar".

Note, incidentally, that in the example above, the statement: bar=$foo
pretty much has to be parsed as if $foo had been quoted, because the
alternative is much worse. The alternative would be to interpret:

bar=$foo
as
bar=foo bar

which means to run the "bar" command with the env var "bar" set to "foo".

--
Trump has normalized hate.

The media has normalized Trump.

On 01.09.2024 09:03, Lawrence D'Oliveiro wrote:
> 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.

Note that it's not a "Bash-ism" - Bash was rarely the _inventor_ of
any shell features, mostly adopted them from other shells, primarily
from Kornshell (still, by far, not catching up).

Kornshell documented that specific feature with its 1993 version.

And we've learned from other replies that it's meanwhile - 30 years
later - already in POSIX. (Good news!)

Janis

On 03.09.2024 20:39, John Ames wrote:
> [...]
> Also, who says that filenames should not, as a rule, contain spaces?

Technically, filenames may even contain ASCII control characters.
Is it wise to use them?

Semantically I'd interpret the term "file name" (and its original
intention) as something different from, erm.., a "file novel".
(I don't want to write "novels" to work with them [in non-GUIs].
I want to spot differences easily, not have to parse the name.)

A file [content] "description" is different from a file "name".
(Note: above term "novel" was just a rhetoric accentuation of
"description".)

The descriptions that some folks stuff into a "file name" should
IMO be part of a file's _meta-information_!
(BTW, like the file's "extension" IMO would also belong there,
like other formal or informal type information about the file.)

It's a historic heritage what we have (strange, OS/FS-dependent,
arbitrary, non-portable, error-prone, etc.). Tedious to discuss.

Define your own standards... - and then live (or die) with them!

Janis

On 05.09.2024 11:29, Ralf Fassel wrote:
> * 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

Quoting is generally the standard way to be on the safe side...

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

There is a problem also with 'echo'...!

space="foo bar"
two_spaces="two spaces"
a_tab="a tab"

# all the IFSs get collapsed in:
echo $space
echo $two_spaces
echo $a_tab

# correct way to handle that:
echo "$space"
echo "$two_spaces"
echo "$a_tab"

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

It's not that confusing if you know the difference between a shell
construct (that doesn't require quotes) and "the all rest" that
needs (for the general case) quotes. If in doubt there's the rule
of thumb to always use quotes.

Janis

>
> R'
>