sh scripting question
bourne.identity at hotmail.com
Fri Oct 16 10:26:13 UTC 2020
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
>>>> 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
> 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
> 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.
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
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.
More information about the freebsd-questions