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". Certainly it can be done, and I do it
when I need to. My point is that there is an advantage in being able to
avoid the extra effort when I know it's not needed.

How would you do it?

> How long
> have you been working with *nix shells?

A long time. I might consider being more specific later.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */

On 2024-09-03, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
> 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 GCC project is Makefile-based.

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.

> The Linux kernel git repo contains 85803 files, and exactly one has
> spaces in its name.

You can bet it's one that's not referenced in any Makefile.

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

The buffoons that use spaces in document names in GUIs will find some
way to confuse themselves, like typing two spaces instead of one, or
quoting names to each other in e-mails without enough delimitation or
use of typeface to know which words are part of the name and which are
surrounding text.

E.g.

A: "Can you send the file analysis and report to me?"
B: "I will report to you, but I can't find the file analysis."
A: "No, the file is called analysis and report. :) Send that to me."

If you follow the convention that name of a file is one word that
contains no leading or trailing punctuation, then you can use it in
written sentences without ambiguity or quotes around it.
You can put a period or comma after it, and know that it can't
be part of the name since it would constitute trailing punctuation.

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

Kaz Kylheku <643-408-1753@kylheku.com> writes:
[...]
> The make utility has no support for paths with spaces.

Looks like you're right. This bug report is 22 years old:

https://savannah.gnu.org/bugs/?712

I'm mildly amused by the fact that I've never noticed this before.

[snip]

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */

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'

I’ve been told elsewhere that $'\n' is also valid in the latest Posix
spec.

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

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
$

I'm using GNU Make 4.3.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */

Lawrence D'Oliveiro <ldo@nz.invalid> writes:
> 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'
>
> I’ve been told elsewhere that $'\n' is also valid in the latest Posix
> spec.

Not bad -- but of course that's not all you have to do.

I tried it just now. My first attempt was

IFS='\n' for file in * ; do cp -p $file $file.bak ; done

but that's a syntax error ("for" is a shell keyword, not a command).
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.

Either of these seems to work:

( IFS='\n' ; for file in * ; do cp -p $file $file.bak ; done )

{ IFS='\n' ; for file in * ; do cp -p $file $file.bak ; done }

That's still more trouble than it's worth *for me*. It handles
99+% of real-world cases, but I expect it would fail if a file had
a newline in its name. (Actually a quick experiment indicates that
that seems to work. I don't know how or why.) I have other ways of
handling this kind of thing if I need 100% reliability regardless of
any funny characters in file names (Perl, readdir). And the simple
"for file in *" handles 99% of the cases that I personally have to
deal with.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:

> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>
>> How long have you been working with *nix shells?
>
> A long time. [...]

My answer is not very long; less than 50 years.

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.

On Tue, 03 Sep 2024 17:27:34 -0700, Keith Thompson wrote:

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

Which in my experience is no biggie.

Next step: what if you wanted to handle newlines in file names as well?

Lawrence D'Oliveiro <ldo@nz.invalid> writes:
> 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".

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */

Lawrence D'Oliveiro <ldo@nz.invalid> writes:
> On Tue, 03 Sep 2024 17:27:34 -0700, Keith Thompson wrote:
>> 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.
>
> Which in my experience is no biggie.

Perhaps. Honestly, I've never paid enough attention to IFS to have any
confidence in doing anything other than leaving it alone.

> Next step: what if you wanted to handle newlines in file names as well?

Either `find ... -print0 | xargs -0 ...` or a quick Perl script.

opendir my $DIR, '.' or die ".: $!\n";
foreach my $file(grep { $_ ne '.' and $_ ne '..' } readdir $DIR) {
system 'cp', '-p', $file, "$file.bak";
# error checking omitted for now
}
closedir $DIR;

(I'm not arguing that Perl is the best or only language for this; it
just happens to be what I'm most familiar with.)

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */

On Tue, 03 Sep 2024 21:29:24 -0700, Keith Thompson wrote:

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

Here’s one I whipped up:

--
output\ file : input\ file
cp "$<" "$@"

input\ file : /dev/null
cp "$<" "$@"
--

If the tabs don’t make it across, you know where they should go. ;)

On Tue, 03 Sep 2024 21:36:48 -0700, Keith Thompson wrote:

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

Sure, it’s much easier in Perl or Python or some other such programming-
oriented (as opposed to command-oriented) language. But it can be done in
Bash.

The thing is, while find is handy for getting the matching file names,
xargs is not always the most convenient way of processing them. You often
just want to be able to do “for f in «filenames»; do «whatever» done”,
e.g.:

collect_expand «wildcard» found_filenames
for f in "${found_filenames[@]}"; do
echo "found" $(printf %q "$f")
done

That “collect_expand” is a Bash function. Do you want to figure out how to
write it, before I post my solution? ;)

On Tue, 3 Sep 2024 16:10:04 -0000 (UTC)
gazelle@shell.xmission.com (Kenny McCormack) boringly babbled:
>In article <20240903084440.0000663d@gmail.com>,
>John Ames <commodorejohn@gmail.com> wrote:
>>On Sat, 31 Aug 2024 08:37:01 -0000 (UTC)
>>Muttley@dastardlyhq.com wrote:
>>
>>> On Sat, 31 Aug 2024 05:57:12 -0000 (UTC)
>>> gazelle@shell.xmission.com (Kenny McCormack) gabbled:
>>> > 2) Spaces in filenames are pretty much a necessity from the
>>> > end-user
>>>
>>> No they're not.
>>
>>WhoNeedsSpacesWhenYouCanJustCapitalizeEveryWordAsAVisualSignifierAmIRight
>>or-alternatively-make-liberal-use-of-dashes
>>or_use_underscores_like_some_deranged_freak
>>
>>Very readable and not at *all* weird or clunky!
>>
>
>I love this post.
>
>Yeah, you got it exactly. Note that users really hate underscores. They

Can you link to the survey which shows this.

On Tue, 3 Sep 2024 08:44:40 -0700
John Ames <commodorejohn@gmail.com> boringly babbled:
>On Sat, 31 Aug 2024 08:37:01 -0000 (UTC)
>Muttley@dastardlyhq.com wrote:
>
>> On Sat, 31 Aug 2024 05:57:12 -0000 (UTC)
>> gazelle@shell.xmission.com (Kenny McCormack) gabbled:
>> > 2) Spaces in filenames are pretty much a necessity from the
>> > end-user
>>
>> No they're not.
>
>WhoNeedsSpacesWhenYouCanJustCapitalizeEveryWordAsAVisualSignifierAmIRight
>or-alternatively-make-liberal-use-of-dashes
>or_use_underscores_like_some_deranged_freak
>
>Very readable and not at *all* weird or clunky!

The camel case isn't great, but the dashes and underscores look fine to me.

On 2024-09-04, Keith Thompson wrote:

> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>> 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.
>>>
[I tried to restore the newlines at the appropriate places here, I hope
I got these right:]
>>> $ 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".

But, in your output, what is having trouble is the compiler invocation,
not make itself processing the files (although that then *is* a problem
with make's implicit rules and their ability to handle spaces).

Or do you mean there is also a problem with detecting the presence or
absence of files with spaces in their names?

--
Nuno Silva

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

R'

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!

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */

In article <vb925l$3oa4b$1@dont-email.me>, <Muttley@dastardlyhq.com> wrote:
....
>>Yeah, you got it exactly. Note that users really hate underscores. They
>
>Can you link to the survey which shows this.

I'm not aware of any such surveys. Are you?

--
Never, ever, ever forget that "Both sides do it" is strictly a Republican meme.

It is always the side that sucks that insists on saying "Well, you suck, too".

On 2024-09-04, Keith Thompson wrote:

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

(Along with these quotes, I'd add ./ before $file.)

--
Nuno Silva

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.

--
"Women should not be enlightened or educated in any way. They should be
segregated because they are the cause of unholy erections in holy men.

-- Saint Augustine (354-430) --

On Wed, 4 Sep 2024 11:27:14 -0000 (UTC)
gazelle@shell.xmission.com (Kenny McCormack) boringly babbled:
>In article <vb925l$3oa4b$1@dont-email.me>, <Muttley@dastardlyhq.com> wrote:
>....
>>>Yeah, you got it exactly. Note that users really hate underscores. They
>>
>>Can you link to the survey which shows this.
>
>I'm not aware of any such surveys. Are you?

Which was my point so you have no way of knowing what users like or don't
like wtf to filenames other than whatever small group you've gone around
and actually asked.

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

HTH
--
Lew Pitcher
"In Skills We Trust"

On 2024-09-04, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
> 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

If you write your own rule in which $@ is quoted as '$@', it will
work, provided it doesn't contain ' characters.

It looks like there is limited support in GNU Make for backslash
escapes: they can be used on the prerequisite and target names
in a rule.

Elsewhere, other than backslash-newline continuations, backslashes
are literal.

So we can do:

FOOBAR := foo\ bar # literal backslash here

$(FOOBAR) : ... # backslash from variable interpolates here

Once the backslash is interpolated into the rule head, it becomes
active, so a single target "foo bar" is specified.

(Unfortunately, what GNU Make should be arguably be doing here is not
just treating foo\ bar as the single target foo bar but also
preserving the backslash so that the item is foo\ bar. Then it would
be possible for the implicit rule to work, because $@ would produce
foo\ bar which would be passed on to the shell, where the backslash
would do its job. One slight problem with that, though, is that the
interpreter for processing recipes is configurable; it doesn't have
to be a POSIX-like shell.)

Anyway, the FOOBAR variable is understood to contain two words, {foo\}
and {bar}. If we do a patsubst on it, it will match separately against
the two. Or foreach will iterate over two items. None of the text
processing stuff in GNU Make will recognize the backslash escape
as preventing word splitting.

Nontrivial Makefiles almost always work with lists, like at the
very least OBJS, SRCS and whatnot.

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