On 15/08/2023 14:34, David Brown wrote:
> On 15/08/2023 09:50, Richard Kettlewell wrote:
>> Kaz Kylheku <864-117-4973@kylheku.com> writes:
>>> On 2023-08-15, Gary R. Schmidt <grschmidt@acm.org> wrote:
>>>> Ahah!  You don't have users, do you?
>>>>
>>>> No doubt you also don't encounter filenames with spaces in them, or
>>>> carriage returns, or other garbage.
>>>
>>> The interesction of:
>>>
>>> - Users who make filenames like "-foo" and "monthly forecast.xls"
>>>
>>> - Users who sit in a POSIX shell expanding wildcards like *
>>>    in the same directory.
>>>
>>> is probababy vanishingly nil, and the subset of those who do the
>>> above in the same directory is even smaller.
>>
>> The cases I’ve encountered are where someone accidentally creates a file
>> with a weird name (starts with - or whatever) and then has trouble
>> deleting it. I don’t think they got as far as having accidents with
>> wildcards in the cases I remember, but the basic setup of a file with a
>> ridiculous name and a non-expert user does happen occasionally.
>>
>
> It's usually sufficient just to put the awkward name inside quotation
> marks.
>
>

But people won't/don't do that.

Also:

$ >-f
$ >-r
$ rm *

How to safely cater for all 'weird' inputs?

Richard Harnden <richard.nospam@gmail.com> writes:
>On 15/08/2023 14:34, David Brown wrote:
>> On 15/08/2023 09:50, Richard Kettlewell wrote:
>>> Kaz Kylheku <864-117-4973@kylheku.com> writes:
>>>> On 2023-08-15, Gary R. Schmidt <grschmidt@acm.org> wrote:
>>>>> Ahah!  You don't have users, do you?
>>>>>
>>>>> No doubt you also don't encounter filenames with spaces in them, or
>>>>> carriage returns, or other garbage.
>>>>
>>>> The interesction of:
>>>>
>>>> - Users who make filenames like "-foo" and "monthly forecast.xls"
>>>>
>>>> - Users who sit in a POSIX shell expanding wildcards like *
>>>>    in the same directory.
>>>>
>>>> is probababy vanishingly nil, and the subset of those who do the
>>>> above in the same directory is even smaller.
>>>
>>> The cases I’ve encountered are where someone accidentally creates a file
>>> with a weird name (starts with - or whatever) and then has trouble
>>> deleting it. I don’t think they got as far as having accidents with
>>> wildcards in the cases I remember, but the basic setup of a file with a
>>> ridiculous name and a non-expert user does happen occasionally.
>>>
>>
>> It's usually sufficient just to put the awkward name inside quotation
>> marks.
>>
>>
>
>But people won't/don't do that.
>
>Also:
>
>$ >-f
>$ >-r
>$ rm *
>
>How to safely cater for all 'weird' inputs?

Well, like any tool, it can be misused. I don't blame
the tool for that, when the tool is still useful.

kalevi@kolttonen.fi (Kalevi Kolttonen) writes:
> 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.
>
> It could happen by accident, but even that is quite
> unlikely.
>
> If "they" don't know how to delete it, there is no need
> to panic. The file's existence does no harm. "They" can
> always ask for help and someone will tell them how
> to get rid of it.
>
> I guess the stdin convention '-' is decades old.
> It was chosen because they had pick something that
> is short and not likely to exist as a real file.

I propose that '|' might have been better - it's even mnemonic.

Phil
--
We are no longer hunters and nomads. No longer awed and frightened, as we have
gained some understanding of the world in which we live. As such, we can cast
aside childish remnants from the dawn of our civilization.
-- NotSanguine on SoylentNews, after Eugen Weber in /The Western Tradition/

Muttley@dastardlyhq.com writes:
> 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.

Your memory if flawed. Spaces were always allowed in unix
filenames. Often used to hide things in plain sight on FTP sites, for
example.

MS Windows didn't allow spaces until Windows 95. I remember the Apple
advert at the time - it was a double-page spread which basically just
said:

C:\NGRTLTNS.W95

in a gajillion-point high font. I pulled that out of a newspaper and
had it on my wall at work. Not because I was an Apple fanboi, far
from it, but my disdain for all things MS Windows was already
entrenched, and I was being forced to use it for the not-the-actual-work
part of my job (which was on Sun workstations).

Phil
--
We are no longer hunters and nomads. No longer awed and frightened, as we have
gained some understanding of the world in which we live. As such, we can cast
aside childish remnants from the dawn of our civilization.
-- NotSanguine on SoylentNews, after Eugen Weber in /The Western Tradition/

On Tue, 15 Aug 2023 23:24:28 +0300, Phil Carmody wrote:

> kalevi@kolttonen.fi (Kalevi Kolttonen) writes:
>> 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.
>>
>> It could happen by accident, but even that is quite
>> unlikely.
>>
>> If "they" don't know how to delete it, there is no need
>> to panic. The file's existence does no harm. "They" can
>> always ask for help and someone will tell them how
>> to get rid of it.
>>
>> I guess the stdin convention '-' is decades old.
>> It was chosen because they had pick something that
>> is short and not likely to exist as a real file.
>
> I propose that '|' might have been better - it's even mnemonic.

But, '|' conflicts with the shell pipe character, and would need
a workaround in some cases. For example,

foo bar | blech

could either pipe stdout from foo (which processed bar) into
blech, or it could instruct foo to accept bar, stdin and blech
as inputs. And, unless you escape or singlequote the pipe character,
the pipe-command interpretation wins.

Similarly,

foo bar - blech

could either ask foo to read files "bar", "-" and "blech"
/or/ ask foo to read files "bar", stdin, and "blech",
depending on the presence (or absence) of a file named "-"
Again, the accepted method of discerning one from the other
is to modify that "-" to "./-", indicating a file (in the
current working directory) named "-".

So, pOHtato, pAHtato.

--
Lew Pitcher
"In Skills We Trust"

kalevi@kolttonen.fi (Kalevi Kolttonen) writes:

> I guess the stdin convention '-' is decades old.
> It was chosen because they had pick something that
> is short and not likely to exist as a real file.

If I were doing this all from scratch, I'd consider choosing /- as the
convention. It's never a "user" file, and anyone capable of creating it
should know how to remove it.

--
Ben.

On 8/15/23 03:50, Richard Kettlewell wrote:
> Kaz Kylheku <864-117-4973@kylheku.com> writes:
....
>> The interesction of:
>>
>> - Users who make filenames like "-foo" and "monthly forecast.xls"
>>
>> - Users who sit in a POSIX shell expanding wildcards like *
>> in the same directory.
>>
>> is probababy vanishingly nil, and the subset of those who do the
>> above in the same directory is even smaller.
>
> The cases I’ve encountered are where someone accidentally creates a file
> with a weird name (starts with - or whatever) and then has trouble
> deleting it. I don’t think they got as far as having accidents with
> wildcards in the cases I remember, but the basic setup of a file with a
> ridiculous name and a non-expert user does happen occasionally.

The most bizarre filenames I've seen were generally created by one of
two mechanisms: Copy-and-pasting a command line into a terminal window,
where a minor slip of the mouse resulted in the copy including far more
material than it was supposed to. Most of the resulting lines of text do
nothing, but every once in a while a line starts with a word that is a
valid unix command name, and some very weird things happen.

The second scenario is where someone stupidly gave an ordinary text file
execute permission, and someone else accidentally typed the name of that
file in a context where it would invoke the supposed "executable". The
results were similar to those from the copy-and-past problem, except
that some of the text files were much longer, increasing the chance of a
line from the file actually resulting in non-trivial behavior.

On Tue, 15 Aug 2023 19:50:44 +0100, Richard Harnden
<richard.nospam@gmail.com> wrote in <ubghe4$2ubhu$1@dont-email.me>:

> On 15/08/2023 14:34, David Brown wrote:
>> On 15/08/2023 09:50, Richard Kettlewell wrote:
>>> Kaz Kylheku <864-117-4973@kylheku.com> writes:
>>>> On 2023-08-15, Gary R. Schmidt <grschmidt@acm.org> wrote:
>>>>> Ahah!  You don't have users, do you?
>>>>>
>>>>> No doubt you also don't encounter filenames with spaces in them, or
>>>>> carriage returns, or other garbage.
>>>>
>>>> The interesction of:
>>>>
>>>> - Users who make filenames like "-foo" and "monthly forecast.xls"
>>>>
>>>> - Users who sit in a POSIX shell expanding wildcards like *
>>>>    in the same directory.
>>>>
>>>> is probababy vanishingly nil, and the subset of those who do the
>>>> above in the same directory is even smaller.
>>>
>>> The cases I’ve encountered are where someone accidentally creates a
>>> file with a weird name (starts with - or whatever) and then has
>>> trouble deleting it. I don’t think they got as far as having accidents
>>> with wildcards in the cases I remember, but the basic setup of a file
>>> with a ridiculous name and a non-expert user does happen occasionally.
>>>
>>>
>> It's usually sufficient just to put the awkward name inside quotation
>> marks.
>>
>>
>>
> But people won't/don't do that.
>
> Also:
>
> $ >-f $ >-r $ rm *
>
> How to safely cater for all 'weird' inputs?

(wondering if this belongs in comp.unix.shell, but here goes:)

In the 90's and maybe the early 2000's, many of our
(large installation) servers had a '-i' file in their
root directories. I'm not sure how widespread the
practice was, but I don't think we invented it.

--
-v

On 15/08/2023 19:08, Joe Pfeiffer wrote:
> Kaz Kylheku <864-117-4973@kylheku.com> writes:
>
>> On 2023-08-15, Gary R. Schmidt <grschmidt@acm.org> wrote:
>>> On 15/08/2023 01:14, Kalevi Kolttonen wrote:
>>>> In comp.unix.programmer Kenny McCormack <gazelle@shell.xmission.com> wrote:
>>>>> You know that - and I know that - but do they know that?
>>>>
>>>> It makes no difference. In the real world nobody has
>>>> files named '-'.
>>>>
>>>> br,
>>>> KK
>>>
>>> Ahah! You don't have users, do you?
>>>
>>> No doubt you also don't encounter filenames with spaces in them, or
>>> carriage returns, or other garbage.
>>
>> The interesction of:
>>
>> - Users who make filenames like "-foo" and "monthly forecast.xls"
>>
>> - Users who sit in a POSIX shell expanding wildcards like *
>> in the same directory.
>>
>> is probababy vanishingly nil, and the subset of those who do the
>> above in the same directory is even smaller.
>>
>> Now admin scripts do have to handle the files created by the goofy users
>> in the first category.
>>
>> Admin scripts don't ahve to worry about users creating a file
>> called -, because admin scripts won't be run in the directory
>> where the user did that. Not even scripts which do process
>> paths traversing that directory. The admin (or cron, or systemd or
>> whatever) will run those from somewhere else.
>
> Though I expect just about everyone has tried to run foo -xyz and
> inadvertently run foo - xyz instead, ending up with a file named - and
> one named xyz.

$ rm -rf * .tmp
rm: .tmp: No such file or directory
$ unrm
-ksh: unrm: not found
$ man cpio

On 16/08/2023 07:37, James Kuyper wrote:
> On 8/15/23 03:50, Richard Kettlewell wrote:
>> Kaz Kylheku <864-117-4973@kylheku.com> writes:
> ...
>>> The interesction of:
>>>
>>> - Users who make filenames like "-foo" and "monthly forecast.xls"
>>>
>>> - Users who sit in a POSIX shell expanding wildcards like *
>>> in the same directory.
>>>
>>> is probababy vanishingly nil, and the subset of those who do the
>>> above in the same directory is even smaller.
>>
>> The cases I’ve encountered are where someone accidentally creates a file
>> with a weird name (starts with - or whatever) and then has trouble
>> deleting it. I don’t think they got as far as having accidents with
>> wildcards in the cases I remember, but the basic setup of a file with a
>> ridiculous name and a non-expert user does happen occasionally.
>
> The most bizarre filenames I've seen were generally created by one of
> two mechanisms: Copy-and-pasting a command line into a terminal window,
> where a minor slip of the mouse resulted in the copy including far more
> material than it was supposed to. Most of the resulting lines of text do
> nothing, but every once in a while a line starts with a word that is a
> valid unix command name, and some very weird things happen.
>
> The second scenario is where someone stupidly gave an ordinary text file
> execute permission, and someone else accidentally typed the name of that
> file in a context where it would invoke the supposed "executable". The
> results were similar to those from the copy-and-past problem, except
> that some of the text files were much longer, increasing the chance of a
> line from the file actually resulting in non-trivial behavior.

I have seen some odd names on file servers, when people have tried to
make certain files sort at the top or bottom of a list by prefixing with
odd characters (such as a space - that's always fun).

Many punctuation marks that are easy to use in gui programs are awkward
on the command line - brackets, quotation marks, ampersand, etc. Mostly
you can handle them on the command line by using quotation marks, or
backslash escapes.

Lew Pitcher <lew.pitcher@digitalfreehold.ca> writes:
> On Tue, 15 Aug 2023 23:24:28 +0300, Phil Carmody wrote:
>> kalevi@kolttonen.fi (Kalevi Kolttonen) writes:
>>> 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.
>>>
>>> It could happen by accident, but even that is quite
>>> unlikely.
>>>
>>> If "they" don't know how to delete it, there is no need
>>> to panic. The file's existence does no harm. "They" can
>>> always ask for help and someone will tell them how
>>> to get rid of it.
>>>
>>> I guess the stdin convention '-' is decades old.
>>> It was chosen because they had pick something that
>>> is short and not likely to exist as a real file.
>>
>> I propose that '|' might have been better - it's even mnemonic.
>
> But, '|' conflicts with the shell pipe character, and would need
> a workaround in some cases. For example,

It's doing something special, why wouldn't you expect to do something
special to make use of it?

Phil
--
We are no longer hunters and nomads. No longer awed and frightened, as we have
gained some understanding of the world in which we live. As such, we can cast
aside childish remnants from the dawn of our civilization.
-- NotSanguine on SoylentNews, after Eugen Weber in /The Western Tradition/

Richard Harnden <richard.nospam@gmail.com> writes:
> On 15/08/2023 19:08, Joe Pfeiffer wrote:
>> Kaz Kylheku <864-117-4973@kylheku.com> writes:
>>> On 2023-08-15, Gary R. Schmidt <grschmidt@acm.org> wrote:
>>>> On 15/08/2023 01:14, Kalevi Kolttonen wrote:
>>>>> In comp.unix.programmer Kenny McCormack <gazelle@shell.xmission.com> wrote:
>>>>>> You know that - and I know that - but do they know that?
>>>>>
>>>>> It makes no difference. In the real world nobody has
>>>>> files named '-'.
>>>>>
>>>>> br,
>>>>> KK
>>>>
>>>> Ahah! You don't have users, do you?
>>>>
>>>> No doubt you also don't encounter filenames with spaces in them, or
>>>> carriage returns, or other garbage.
>>>
>>> The interesction of:
>>>
>>> - Users who make filenames like "-foo" and "monthly forecast.xls"
>>>
>>> - Users who sit in a POSIX shell expanding wildcards like *
>>> in the same directory.
>>>
>>> is probababy vanishingly nil, and the subset of those who do the
>>> above in the same directory is even smaller.
>>>
>>> Now admin scripts do have to handle the files created by the goofy users
>>> in the first category.
>>>
>>> Admin scripts don't ahve to worry about users creating a file
>>> called -, because admin scripts won't be run in the directory
>>> where the user did that. Not even scripts which do process
>>> paths traversing that directory. The admin (or cron, or systemd or
>>> whatever) will run those from somewhere else.
>>
>> Though I expect just about everyone has tried to run foo -xyz and
>> inadvertently run foo - xyz instead, ending up with a file named - and
>> one named xyz.
>
> $ rm -rf * .tmp
> rm: .tmp: No such file or directory
> $ unrm
> -ksh: unrm: not found
> $ man cpio

Spurious spaces are less common than this mistake, which I have seen
done by someone (who was at elevated privs at the time):

# rm *>o

(For those in exotic-keyboard-land: '>' was shifted '.', thus the
shift required for '*' hadn't been released yet.)

Phil
--
We are no longer hunters and nomads. No longer awed and frightened, as we have
gained some understanding of the world in which we live. As such, we can cast
aside childish remnants from the dawn of our civilization.
-- NotSanguine on SoylentNews, after Eugen Weber in /The Western Tradition/

On Wed, 16 Aug 2023 17:11:28 +0300, Phil Carmody wrote:

> Lew Pitcher <lew.pitcher@digitalfreehold.ca> writes:
>> On Tue, 15 Aug 2023 23:24:28 +0300, Phil Carmody wrote:
[snip]
>>>> I guess the stdin convention '-' is decades old.
>>>> It was chosen because they had pick something that
>>>> is short and not likely to exist as a real file.
>>>
>>> I propose that '|' might have been better - it's even mnemonic.
>>
>> But, '|' conflicts with the shell pipe character, and would need
>> a workaround in some cases. For example,
>
> It's doing something special, why wouldn't you expect to do something
> special to make use of it?

Okay, then. How about a counter proposal:
For Unix shells, the < character indicates redirection of stdin.
I propose that '<' might have been a better choice as a standard
program option to flag "read from stdin" than either '|' /or/ '-'
were. :-)

--
Lew Pitcher
"In Skills We Trust"

David Brown <david.brown@hesbynett.no> writes:
> On 15/08/2023 09:50, Richard Kettlewell wrote:
>> The cases I’ve encountered are where someone accidentally creates a
>> file with a weird name (starts with - or whatever) and then has
>> trouble deleting it. I don’t think they got as far as having
>> accidents with wildcards in the cases I remember, but the basic setup
>> of a file with a ridiculous name and a non-expert user does happen
>> occasionally.
>
> It's usually sufficient just to put the awkward name inside quotation marks.

In the case we started with, quoting is not sufficient.

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

Richard Kettlewell <invalid@invalid.invalid> writes:
>David Brown <david.brown@hesbynett.no> writes:
>> On 15/08/2023 09:50, Richard Kettlewell wrote:
>>> The cases I’ve encountered are where someone accidentally creates a
>>> file with a weird name (starts with - or whatever) and then has
>>> trouble deleting it. I don’t think they got as far as having
>>> accidents with wildcards in the cases I remember, but the basic setup
>>> of a file with a ridiculous name and a non-expert user does happen
>>> occasionally.
>>
>> It's usually sufficient just to put the awkward name inside quotation marks.
>
>In the case we started with, quoting is not sufficient.

Doesn't that depend on the type of quote? glob characters (*, ?) are
treated as regular characters in single quotes, for example.

In article <TP7DM.428701$U3w1.87269@fx09.iad>,
Scott Lurndal <slp53@pacbell.net> wrote:
>Richard Kettlewell <invalid@invalid.invalid> writes:
>>David Brown <david.brown@hesbynett.no> writes:
>>> On 15/08/2023 09:50, Richard Kettlewell wrote:
>>>> The cases Ive encountered are where someone accidentally creates a
>>>> file with a weird name (starts with - or whatever) and then has
>>>> trouble deleting it. I dont think they got as far as having
>>>> accidents with wildcards in the cases I remember, but the basic setup
>>>> of a file with a ridiculous name and a non-expert user does happen
>>>> occasionally.
>>>
>>> It's usually sufficient just to put the awkward name inside
>>> quotation marks.
>>
>>In the case we started with, quoting is not sufficient.
>
>Doesn't that depend on the type of quote? glob characters (*, ?) are
>treated as regular characters in single quotes, for example.

You're missing the point.

--
Treating the stock market indexes as general measures of the well-being of a
society is like treating your blood pressure as an indicator of health. The
higher, the better, right? In fact, a high stock market is good for the investor
class, but it means the rest of us are getting screwed better than ever.

On 2023-08-16, Lew Pitcher <lew.pitcher@digitalfreehold.ca> wrote:
> On Wed, 16 Aug 2023 17:11:28 +0300, Phil Carmody wrote:
>
>> Lew Pitcher <lew.pitcher@digitalfreehold.ca> writes:
>>> On Tue, 15 Aug 2023 23:24:28 +0300, Phil Carmody wrote:
> [snip]
>>>>> I guess the stdin convention '-' is decades old.
>>>>> It was chosen because they had pick something that
>>>>> is short and not likely to exist as a real file.
>>>>
>>>> I propose that '|' might have been better - it's even mnemonic.
>>>
>>> But, '|' conflicts with the shell pipe character, and would need
>>> a workaround in some cases. For example,
>>
>> It's doing something special, why wouldn't you expect to do something
>> special to make use of it?
>
> Okay, then. How about a counter proposal:
> For Unix shells, the < character indicates redirection of stdin.
> I propose that '<' might have been a better choice as a standard
> program option to flag "read from stdin" than either '|' /or/ '-'
> were. :-)

Counter-counter proposal #1:

The issue is that "commmand *" can generate the - name
or arguments that look like options.

But * skips things that begin with dot!

So, use that for options:

rm .rf *

Counter-couner proposal #2:

Problem is that we often operate on dot files.

Solution: have it so that * skips names that start with
dash; so if someone wants * to match - or -rf, they
must use "command -*".

Bash could have a "shopt -s dashglob" to make *
match dashed items.

I think it might be worth implementing dashglob Bash,
enabled by default.

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

scott@slp53.sl.home (Scott Lurndal) writes:
> Richard Kettlewell <invalid@invalid.invalid> writes:
>>David Brown <david.brown@hesbynett.no> writes:
>>> On 15/08/2023 09:50, Richard Kettlewell wrote:
>>>> The cases I’ve encountered are where someone accidentally creates a
>>>> file with a weird name (starts with - or whatever) and then has
>>>> trouble deleting it. I don’t think they got as far as having
>>>> accidents with wildcards in the cases I remember, but the basic setup
>>>> of a file with a ridiculous name and a non-expert user does happen
>>>> occasionally.
>>>
>>> It's usually sufficient just to put the awkward name inside quotation marks.
>>
>>In the case we started with, quoting is not sufficient.
>
> Doesn't that depend on the type of quote? glob characters (*, ?) are
> treated as regular characters in single quotes, for example.

Not in this case -- and glob characters are not expanded in either
single or doublle quotes.

The difference is that * and ? are expanded by the shell, so the
invoked command never sees them, but arguments starting with -
are treated specially by the command itself.

If you have a file named *, you can delete it with `rm '*'` or
`rm "*"`, or `rm \*`.

If you have a file named -r, you can delete it with `rm ./-r`, or
`rm -- -r` if your rm implementation supports that (POSIX doesn't
specify it).

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

On Tue, 15 Aug 2023 16:22:16 -0000 (UTC)
kalevi@kolttonen.fi (Kalevi Kolttonen) wrote:
>In comp.unix.programmer 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.
>
>Filenames having spaces versus the stdin convention '-' is
>comparing two things that are very different.
>
>The first one is just a way to name files or directories.
>
>The second one is an age-old Unix convention that has
>nothing to do with naming real files or directories.
>
>It is best to not to confuse these two distinct ideas.

They both cause problems.

On Tue, 15 Aug 2023 23:32:22 +0300
Phil Carmody <pc+usenet@asdf.org> wrote:
>Muttley@dastardlyhq.com writes:
>> 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.
>
>Your memory if flawed. Spaces were always allowed in unix
>filenames. Often used to hide things in plain sight on FTP sites, for
>example.

Any character from 0-255 is allowed in unix filenames but only an idiot would
use spaces and non printing characters.

>MS Windows didn't allow spaces until Windows 95. I remember the Apple

DOS didn't like filenames more than 8 characters long and required a TLA.
So what?

It has become a standard in windows to use spaces in filenames no doubt due
to the hopeless command line interface so there was no necessity to play nice
with command line tools that by default use whitespace as field seperators.

>had it on my wall at work. Not because I was an Apple fanboi, far
>from it, but my disdain for all things MS Windows was already
>entrenched, and I was being forced to use it for the not-the-actual-work
>part of my job (which was on Sun workstations).

Apple arguably are even worse right now - case aware but case insensitive
unless you use wildcards on the command line when suddenly case matters again.
Hopeless.

eg:
fenris$ touch HELLO
fenris$ ls hello
hello
fenris$ ls H*
HELLO
fenris$ ls h*
ls: h*: No such file or directory

Lew Pitcher <lew.pitcher@digitalfreehold.ca> writes:
> On Wed, 16 Aug 2023 17:11:28 +0300, Phil Carmody wrote:
>> Lew Pitcher <lew.pitcher@digitalfreehold.ca> writes:
>>> On Tue, 15 Aug 2023 23:24:28 +0300, Phil Carmody wrote:
> [snip]
>>>>> I guess the stdin convention '-' is decades old.
>>>>> It was chosen because they had pick something that
>>>>> is short and not likely to exist as a real file.
>>>>
>>>> I propose that '|' might have been better - it's even mnemonic.
>>>
>>> But, '|' conflicts with the shell pipe character, and would need
>>> a workaround in some cases. For example,
>>
>> It's doing something special, why wouldn't you expect to do something
>> special to make use of it?
>
> Okay, then. How about a counter proposal:
> For Unix shells, the < character indicates redirection of stdin.
> I propose that '<' might have been a better choice as a standard
> program option to flag "read from stdin" than either '|' /or/ '-'
> were. :-)

Why *better* than '|', rather than *equally good as*, given that the
logic is absolutely equivalent?

Phil
--
We are no longer hunters and nomads. No longer awed and frightened, as we have
gained some understanding of the world in which we live. As such, we can cast
aside childish remnants from the dawn of our civilization.
-- NotSanguine on SoylentNews, after Eugen Weber in /The Western Tradition/

scott@slp53.sl.home (Scott Lurndal) writes:
> Richard Kettlewell <invalid@invalid.invalid> writes:
>>David Brown <david.brown@hesbynett.no> writes:
>>> On 15/08/2023 09:50, Richard Kettlewell wrote:
>>>> The cases I’ve encountered are where someone accidentally creates a
>>>> file with a weird name (starts with - or whatever) and then has
>>>> trouble deleting it. I don’t think they got as far as having
>>>> accidents with wildcards in the cases I remember, but the basic setup
>>>> of a file with a ridiculous name and a non-expert user does happen
>>>> occasionally.
>>>
>>> It's usually sufficient just to put the awkward name inside quotation marks.
>>
>>In the case we started with, quoting is not sufficient.
>
> Doesn't that depend on the type of quote? glob characters (*, ?) are
> treated as regular characters in single quotes, for example.

No, it depends on the program you intend to pass the filename to, and
how it treats its arguments.

Which we don't know. So we can't say anything more at the moment.

Phil
--
We are no longer hunters and nomads. No longer awed and frightened, as we have
gained some understanding of the world in which we live. As such, we can cast
aside childish remnants from the dawn of our civilization.
-- NotSanguine on SoylentNews, after Eugen Weber in /The Western Tradition/

Muttley@dastardlyhq.com writes:
> On Tue, 15 Aug 2023 23:32:22 +0300
> Phil Carmody <pc+usenet@asdf.org> wrote:
>>Muttley@dastardlyhq.com writes:
>>> 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.
>>
>>Your memory if flawed. Spaces were always allowed in unix
>>filenames. Often used to hide things in plain sight on FTP sites, for
>>example.
>
> Any character from 0-255 is allowed in unix filenames but only an idiot would
> use spaces and non printing characters.
>
>>MS Windows didn't allow spaces until Windows 95. I remember the Apple
>
> DOS didn't like filenames more than 8 characters long and required a TLA.
> So what?
>
> It has become a standard in windows to use spaces in filenames no doubt due
> to the hopeless command line interface so there was no necessity to play nice
> with command line tools that by default use whitespace as field seperators.
>
>>had it on my wall at work. Not because I was an Apple fanboi, far
>>from it, but my disdain for all things MS Windows was already
>>entrenched, and I was being forced to use it for the not-the-actual-work
>>part of my job (which was on Sun workstations).
>
> Apple arguably are even worse right now - case aware but case insensitive
> unless you use wildcards on the command line when suddenly case matters again.
> Hopeless.
>
> eg:
> fenris$ touch HELLO
> fenris$ ls hello
> hello
> fenris$ ls H*
> HELLO
> fenris$ ls h*
> ls: h*: No such file or directory

That I didn't know. Wow - if that's an actual interactive session being
quoted, that's frightening. Thanks for reminding me why my installation
of linux on my Apple G5 box wasn't moment too soon. How can people live
with such wrongthink? Stockholm Syndrome?

Mind geboggled,
Phil
--
We are no longer hunters and nomads. No longer awed and frightened, as we have
gained some understanding of the world in which we live. As such, we can cast
aside childish remnants from the dawn of our civilization.
-- NotSanguine on SoylentNews, after Eugen Weber in /The Western Tradition/

On Thursday, August 17, 2023 at 2:58:01 PM UTC+3, Phil Carmody wrote:
> Mut...@dastardlyhq.com writes:
> > On Tue, 15 Aug 2023 23:32:22 +0300
> > Phil Carmody <pc+u...@asdf.org> wrote:
> >>Mut...@dastardlyhq.com writes:
> >>> On Tue, 15 Aug 2023 16:12:19 -0000 (UTC)
> >>> kal...@kolttonen.fi (Kalevi Kolttonen) wrote:
> >>>>Kenny McCormack <gaz...@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.
> >>
> >>Your memory if flawed. Spaces were always allowed in unix
> >>filenames. Often used to hide things in plain sight on FTP sites, for
> >>example.
> >
> > Any character from 0-255 is allowed in unix filenames but only an idiot would
> > use spaces and non printing characters.
> >
> >>MS Windows didn't allow spaces until Windows 95. I remember the Apple
> >
> > DOS didn't like filenames more than 8 characters long and required a TLA.
> > So what?
> >
> > It has become a standard in windows to use spaces in filenames no doubt due
> > to the hopeless command line interface so there was no necessity to play nice
> > with command line tools that by default use whitespace as field seperators.
> >
> >>had it on my wall at work. Not because I was an Apple fanboi, far
> >>from it, but my disdain for all things MS Windows was already
> >>entrenched, and I was being forced to use it for the not-the-actual-work
> >>part of my job (which was on Sun workstations).
> >
> > Apple arguably are even worse right now - case aware but case insensitive
> > unless you use wildcards on the command line when suddenly case matters again.
> > Hopeless.
> >
> > eg:
> > fenris$ touch HELLO
> > fenris$ ls hello
> > hello
> > fenris$ ls H*
> > HELLO
> > fenris$ ls h*
> > ls: h*: No such file or directory
> That I didn't know. Wow - if that's an actual interactive session being
> quoted, that's frightening. Thanks for reminding me why my installation
> of linux on my Apple G5 box wasn't moment too soon. How can people live
> with such wrongthink? Stockholm Syndrome?
>
> Mind geboggled,
> Phil
> --
> We are no longer hunters and nomads. No longer awed and frightened, as we have
> gained some understanding of the world in which we live. As such, we can cast
> aside childish remnants from the dawn of our civilization.
> -- NotSanguine on SoylentNews, after Eugen Weber in /The Western Tradition/

Most computer users don't use command line. More so, I would think that most
computer users do not know that command line exists.
I'd guess that if shown command line many of them would say that it's people
like us that continue to insist on using command line are suffering from some
type of unhealthy mental syndrome.

On 2023-08-17, Muttley@dastardlyhq.com <Muttley@dastardlyhq.com> wrote:
> Any character from 0-255 is allowed in unix filenames but only an idiot would
> use spaces and non printing characters.

That's simply false. 0 is the null terminator and is not actually part
of the name. The path-component-separating slash cannot be contained in
a path component; there is no escape mechanism to include it.

POSIX defines a set of characters which are recommended for use in file
names for portability; it is wise for applications and users to stick to
that.

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