sh scripting question

[Manish Jain]

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 <bourne.identity at hotmail.com>
>> To: Ralf Mardorf <ralf-mardorf at riseup.net>
>>
>> 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 at archlinux tmp]$ cat --help | head -1
> Usage: cat [OPTION]... [FILE]...
> [rocketmouse at 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.


Regards,
Manish Jain