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.

br,
KK

On 2023-08-15, Muttley@dastardlyhq.com <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.

Windows users typically do not name files "-" either,
in spite of there being spaces in file and directory names.

A program that handles - specially will not be confused when
that occurs in a path like /abc/-/def or ./- or -/ and other
possibilities.

Windows has worse problems, like issues if you try to make
a file called PRN in any directory.

"* Do not use the following reserved names for the name of a file:

CON, PRN, AUX, NUL, COM0, COM1, COM2, COM3, COM4, COM5, COM6, COM7,
COM8, COM9, LPT0, LPT1, LPT2, LPT3, LPT4, LPT5, LPT6, LPT7, LPT8,
and LPT9. Also avoid these names followed immediately by an
extension; for example, NUL.txt and NUL.tar.gz are both equivalent
to NUL. For more information, see Namespaces."

In Microsoft Teams, channel names cannot have MS-DOS device names:

https://learn.microsoft.com/en-us/microsoftteams/limits-specifications-teams

"Channel names can't contain the following characters or words:

[...]

Words forms, CON, CONIN$, CONOUT$, PRN, AUX, NUL, COM1 to COM9, LPT1
to LPT9, desktop.ini, _vti_

LOL ...

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

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.

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 Wed, 16 Aug 2023 17:37:55 GMT
scott@slp53.sl.home (Scott Lurndal) 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 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.

The issue is whether a filename may be confused for an option if the
filename starts with - .Quoting isn't going to help with that.

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

On 2023-08-16, Spiros Bousbouras <spibou@gmail.com> wrote:
> On Wed, 16 Aug 2023 17:37:55 GMT
> scott@slp53.sl.home (Scott Lurndal) 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 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.
>
> The issue is whether a filename may be confused for an option if the
> filename starts with - .Quoting isn't going to help with that.

It does. There is a quoting mechanism -- which says "the following
arguments are literal even if they look like options".

It's a token-level quote. The "--" token escapes a following "-rf"
token, and others after it.

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

On 2023-08-16, Kaz Kylheku <864-117-4973@kylheku.com> wrote:
> On 2023-08-16, Spiros Bousbouras <spibou@gmail.com> wrote:
>> On Wed, 16 Aug 2023 17:37:55 GMT
>> scott@slp53.sl.home (Scott Lurndal) 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 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.
>>
>> The issue is whether a filename may be confused for an option if the
>> filename starts with - .Quoting isn't going to help with that.
>
> It does. There is a quoting mechanism -- which says "the following
> arguments are literal even if they look like options".
>
> It's a token-level quote. The "--" token escapes a following "-rf"
> token, and others after it.

Ah, but of course, that is of no help with -, which is a non-option
argument.

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