Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 16 Oct 2020 15:55:59 +0530
From:      Manish Jain <>
To:        Ralf Mardorf <>,
Subject:   Re: sh scripting question
Message-ID:  <>
In-Reply-To: <20201016113408.16d58d68@archlinux>
References:  <> <> <20201016113408.16d58d68@archlinux>

Next in thread | Previous in thread | Raw E-Mail | Index | Archive | Help

On 2020-10-16 15:04, Ralf Mardorf wrote:
> On Fri, 16 Oct 2020 13:42:17 +0530, Manish Jain wrote:
>> -------- Forwarded Message --------
>> Subject: Re: sh scripting question
>> Date: Fri, 16 Oct 2020 13:39:06 +0530
>> From: Manish Jain <>
>> To: Ralf Mardorf <>
>> On 2020-10-16 10:02, Ralf Mardorf wrote:
>>> On Thu, 15 Oct 2020 23:14:13 -0400, Kurt Hackenberg wrote:
>>>> On 2020-10-15 23:05, Bob Proulx wrote:
>>>>> Oh you are tormenting us now.  :-)  There are some subtle issues
>>>>> here.
>>>> Maybe a shell is the wrong tool.
>>> Exactly! Scripts are useful to handle tasks, such as dealing with
>>> reasonable file names. A script should work around reasonable tricky
>>> file names, but at some point bothering with really freakish file
>>> names isn't worth the effort. Actually file names should be
>>> compatible with shell, if they are intended to be used with shell
>>> scripts. To some extent we could use shell scripts, to write little
>>> programs, that probably better should be written in a programming
>>> language. At some extent a programming language is required, a shell
>>> script can't do the job at all or at best it could do the job, but
>>> not with reasonable effort.
>> I would strongly disagree with that. If a problem can be solved with a
>> shell script - and Robert Huff's problem is easily solvable with a
>> simple Bourne shell script, then a shell script must be what is used
>> to solve the problem.
> We do not disagree here. The OP's "problem" isn't a big problem for a
> shell script, assuming we are talking about file names such as
> foo bar 10-inch.txt
> and not
>   foo  "bar"      \      10".txt
> Names read from a file containing a list of file names is one thing. The
> next step is how the script should proceed using the file names.
> Handling even the most freakish string is doable, but depending on
> what should be done next with this string, it's not necessarily
> pleasant, especially not when the content of the string conflicts with
> shell conventions.
> Imagine a file named
> -
> or
> -h
> or
> --help
> etc., then add the file name behind a command.
> Yes, you could use a workaround, such as adding a path.
> [rocketmouse@archlinux tmp]$ cat --help | head -1
> Usage: cat [OPTION]... [FILE]...
> [rocketmouse@archlinux tmp]$ cat ./--help | head -1
> test
> However, you easily could end up with a script containing more lines
> that workaround offended conventions, than containing lines for what
> actually should be done.

Hi Ralf,

This is where I actually have an entirely different philosophy. When you 
create a file with a leading - (or for that matter, weird characters 
such as * anywhere in the filename), I think the filesystem driver (i.e. 
the kernel) should throw a warning: "Do you really want a filename like 
that ?"

Actually, I would go one step ahead and have kernel drivers and users 
agree on a Unix Portable File Naming Convention, which should debar 
rotten file names in the first place to everyone except the root user 
(and even he should get a warning on violations).

A few examples of what the Convention should debar:

- in the leading position
. in the trailing position
* anywhere in the filename
| anywhere in the filename

I could think of a few more, but I think you get the idea.

Anyway, Robert's problem I do not think relates to weird filenames as 
far as I can see.

Manish Jain

Want to link to this message? Use this URL: <>