In article <ubg8a8$2t20l$1@dont-email.me>, <Muttley@dastardlyhq.com> wrote:
>On Tue, 15 Aug 2023 16:12:19 -0000 (UTC)
>kalevi@kolttonen.fi (Kalevi Kolttonen) wrote:
>>Kenny McCormack <gazelle@shell.xmission.com> wrote:
>>> But do they know that???
>>
>>"They" probably don't know it. But let's face it,
>>nobody really wants to create a file having '-'
>>filename on purpose. The filename is not descriptive
>>at all, it would be just an insane choice for anything
>>useful.
>
>I used to think the same thing about spaces in filenames. Then along came
>Windows.
>

(I happened to be re-reading this 1 year old thread, so thought I'd add a
post to it)

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. I have always thought that the right answer is
to have both - a short name that is usable for the admin side of
the game and a long label that the user can work with. There are
two solutions of this nature that I like:
a) The "Extend a name" idea. Where you have short names at the
filesystem level, but then have a database linked to that
that allows the user to think that long, descriptive
filenames are supported.

A long long time ago, there was a DOS product called
"Extend a name" that did this. Also, 4DOS (and later
versions) does this.
b) The way VFAT does it (and NTFS emulates) - where, for any
file with a long name, there is an 8.3 filename (usually
with weird characters in the filename) as well, and either
filename is usable by programs. This is one place where I
think Windows really gets it right (and Unix could learn
from it).

--
He continues to assert that 2 plus 2 equals 4, despite being repeatedly
told otherwise.

gazelle@shell.xmission.com (Kenny McCormack) writes:
> 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.

The historical advantage of the free-for-all Unix approach is that
allowed flexibility in filename encoding. Today it’d work to say “UTF-8
only” (and maybe other restrictions) but that wasn’t always the case.
The original design has saved us from a bit of path dependency.

In the application-facing API (open, CreateFile, etc), the rule pretty
much has to be ‘anything goes’, because you may be dealing with a
‘foreign’ filesystem (e.g. via a network filesystem). I don’t want to be
unable to access an existing file just because two computers have
different sets of restrictions on filenames.

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

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

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

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.

> b) The way VFAT does it (and NTFS emulates) - where, for any
> file with a long name, there is an 8.3 filename (usually
> with weird characters in the filename) as well, and either
> filename is usable by programs. This is one place where I
> think Windows really gets it right (and Unix could learn
> from it).

No, just no. The windows "solution" is a hideous hack only required for
backwards compatability.

On Sat, 31 Aug 2024 09:27:44 +0100
Richard Kettlewell <invalid@invalid.invalid> gabbled:
>gazelle@shell.xmission.com (Kenny McCormack) writes:
>> 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.
>

When parsing is based around words on a line how else exactly would you expect
it to be done? Every language tokenises based in seperators so unless you
expect the shell to automagically figure out when a filename ends and the next
part of the command begins then I would suggest using quotes is a solution
thats worked for decades and works fine.

On Sat, 31 Aug 2024 09:27:44 +0100, Richard Kettlewell wrote:

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

The nice thing about Unicode is the alternatives it offers: so you can’t
use “/” in a filename, but you can use “∕” instead.

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

I think it’s still possible to assign a newline to $IFS, it just takes a
bit more work.

On 2024-09-01, 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.
>
> I think it’s still possible to assign a newline to $IFS, it just takes a
> bit more work.

Perhaps using the printf utility? It is in IEEE 1003.1 (p3049 in -2008).

--
Nuno Silva

Am 31.08.24 um 07:57 schrieb Kenny McCormack:
> 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 have always thought that the right answer is
> to have both - a short name that is usable for the admin side of
> the game and a long label that the user can work with. There are
> two solutions of this nature that I like:
> a) The "Extend a name" idea. Where you have short names at the
> filesystem level, but then have a database linked to that
> that allows the user to think that long, descriptive
> filenames are supported.
>
> A long long time ago, there was a DOS product called
> "Extend a name" that did this. Also, 4DOS (and later
> versions) does this.

OS/2 also had the "display file name" approach for invalid file names.

> b) The way VFAT does it (and NTFS emulates) - where, for any
> file with a long name, there is an 8.3 filename (usually
> with weird characters in the filename) as well, and either
> filename is usable by programs. This is one place where I
> think Windows really gets it right (and Unix could learn
> from it).
>

In fact both variants caused at least as much problems as they solved.

First of all the relation between the two file names is usually lost, if
a system that is not aware of them is used to move or copy a file.

Secondly the raw file names in the backend can cause significant false
positives with wildcard matching. E.g. when you delete *2.txt it is
likely that a bunch of mangled file names match too.

Last but not least sometimes the display file name is used to translate
system folder names into the users language. Besides the false positive
problem this makes it difficult to find the raw name for the user.
(Of course, translated system folders like "Programme" or
"Arbeitsoberfläche" caused other problems.)

At the end I always disabled the two file mane approach wherever
possible. (NTFS, Samba ...)
If an old OS is not aware of accessing certain file names, it should not
be used for this kind of data.

Marcel

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

newline="$( printf '%b.' '\n' )" && newline="${newline%?}"

As this is a problem with the shell, I suggest Followup-To
"comp.unix.shell"

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

If one wants to cope with any character (including newline
characters) in the POSIX shell's command line, one could make use
of the apostroph quoting mechanism.

If one wants to process arbitrary (may be generated) lists of
filenames, one could make use of the "xargs" utility with option
"-0".

To generate those lists of filenames, there are

find ... -print0

and

printf '%s\0' ...

available.

Followup-To: comp.unix.shell

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!

John Ames <commodorejohn@gmail.com> writes:
>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!
>

Perhaps Dennis had it right with a 14-character maximum filename :-)

On Tue, 03 Sep 2024 15:47:23 +0000, Scott Lurndal wrote:

> John Ames <commodorejohn@gmail.com> writes:
>>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!
>>
>
> Perhaps Dennis had it right with a 14-character maximum filename :-)

Only because space was tight on those early disk drives, and they
only allocated 16 bytes for each directory entry (2 bytes inode#,
14 bytes filename).

:-)

--
Lew Pitcher
"In Skills We Trust"

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
hate them as much as (or more than) we, the admins, love them. So, your
comment about "deranged freak" is spot on.

--
Elect a clown, expect a circus.

On 2024-09-03, 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

This is a strawman argument; filenamews should not only not have spaces,
but should be reasonably short. (No, not 8.3 short; that's not
"reasonably" and therefore another strawman.)

If we use spaces in your examples, the readability improves, but if you
have a directory of just half a dozen such names, you've got a paragraph
to read.

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

On 9/1/2024 3:03 AM, 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.

Actually, dollar quotes were added to POSIX as of SUS Issue 8:

"2.2.4 Dollar-Single-Quotes
A sequence of characters starting with a <dollar-sign> immediately followed
by a single-quote ($') shall preserve the literal value of all characters up to
an unescaped terminating single-quote ('), with the exception of certain
<backslash>-escape sequences, as follows:
...."

<https://pubs.opengroup.org/onlinepubs/9799919799/>

--
Wayne

On Tue, 3 Sep 2024 17:37:21 -0000 (UTC)
Kaz Kylheku <643-408-1753@kylheku.com> wrote:

> On 2024-09-03, 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
>
> This is a strawman argument; filenamews should not only not have
> spaces, but should be reasonably short. (No, not 8.3 short; that's not
> "reasonably" and therefore another strawman.)
>
> If we use spaces in your examples, the readability improves, but if
> you have a directory of just half a dozen such names, you've got a
> paragraph to read.

I'm unclear on how that qualifies as a straw-man argument...? Also, who
says that filenames should not, as a rule, contain spaces?

On 2024-09-03, John Ames <commodorejohn@gmail.com> wrote:
> On Tue, 3 Sep 2024 17:37:21 -0000 (UTC)
> Kaz Kylheku <643-408-1753@kylheku.com> wrote:
>
>> On 2024-09-03, 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
>>
>> This is a strawman argument; filenamews should not only not have
>> spaces, but should be reasonably short. (No, not 8.3 short; that's not
>> "reasonably" and therefore another strawman.)
>>
>> If we use spaces in your examples, the readability improves, but if
>> you have a directory of just half a dozen such names, you've got a
>> paragraph to read.
>
> I'm unclear on how that qualifies as a straw-man argument...?

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!

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

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.

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

For people who exclusively use GUIs, spaces in a field are not a problem.

For people who work from the command line, spaces suck and are completely
unnecessary and even a PITA and moreover, a potential security issue.

I've not found a need for whitespace in a filesystem over the last 45 years
of interactive computer usage. YMMV.

On Tue, 03 Sep 2024 20:34:37 GMT, Scott Lurndal wrote:

> For people who work from the command line, spaces suck and are
> completely unnecessary and even a PITA and moreover, a potential
> security issue.

I work heavily from the command line. I like having spaces in file/
directory names, and I regularly use them.

On Tue, 3 Sep 2024 13:56:08 -0400, Wayne wrote:

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

Glad to know. I was looking at the man page for dash(1) as my reference
for a vanilla POSIX shell.

<https://manpages.debian.org/1/dash.1.en.html>

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. In either cases, I don't know whether this is
due to some hard rule.

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

(Yes, this skips files whose names start with '.'; I usually don't
need to worry about that) I never (well, hardly ever) create files
with spaces in their names. I typically use '-' rather than '
' to delimit words in file names. When I have to work with such
files, I can do it, but it requires a bit of extra effort.

And if, for example, I'm writing a shell script that needs to be
generally useful, I'll spend the extra effort to make sure it works
with arbitrary file names (or I'll write it in a scripting language
where it's not an issue). But I don't typically bother if I know
I'm working with files that I created.

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.

--
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 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. How long
>have you been working with *nix shells?

Longer than you.