In article <758f0a4b-d8c9-44db-af3e-2c8ac1ff2354n@googlegroups.com>,
Malcolm McLean <malcolm.arthur.mclean@gmail.com> wrote:
....
>I've just coded in this line.
>
> help = opt_get(opt, "-help -h -H --help /H -?", 0);
>
>On systems which expand wildcards in the shell, you have to type
>xmltocsv "-?" to trigger help with the question mark option. But on
>Windows it should work fine. Of course if you have an Xml file named
>"H" in the root directory then you are in trouble. But you can pipe it
>to stdin and convert it that way.

I don't know if you're read/parsed my earlier responses on this thread
(yet), but I still think it is perfectly reasonable to display the help
message when the program is run with no args and stdin is a terminal (as
checked with isatty()). You can then also display it on any other arg
error; this eliminates any need to check explicitly for
-h/-H/-?/--help/etc, etc.

isatty() works on Unix/Linux/MacOS, but I suppose may not work in (native)
Windows. I don't know if it works in Cygwin/WSL/etc (It probably does;
I've just never checked it).

Alternatively, you could dispense with isatty() and require a - as a
(pseudo-) filename to read stdin.

--
The last time a Republican cared about you, you were a fetus.

In article <874jl1j4rh.fsf@bsb.me.uk>,
Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
....
>Agreed. And newer programs will follow the ancient convention. The
>distinction, it seems to me, is not age but purpose. If you can easily
>see a program being used in a pipeline, it should silently read stdin,

No. As I mentioned earlier, if "cat" (et al) was being designed today, it
wouldn't work like that.

Remember that, in the early days of Unix, typing commands on a 110 baud
teletype, keeping typing to an absolute minimum was a top priority. Today,
not so much.

--
The randomly chosen signature file that would have appeared here is more than 4
lines long. As such, it violates one or more Usenet RFCs. In order to remain
in compliance with said RFCs, the actual sig can be found at the following URL:
http://user.xmission.com/~gazelle/Sigs/FreeCollege

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

gazelle@shell.xmission.com (Kenny McCormack) writes:
>In article <874jl1j4rh.fsf@bsb.me.uk>,
>Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
>...
>>Agreed. And newer programs will follow the ancient convention. The
>>distinction, it seems to me, is not age but purpose. If you can easily
>>see a program being used in a pipeline, it should silently read stdin,
>
>No. As I mentioned earlier, if "cat" (et al) was being designed today, it
>wouldn't work like that.

Why do you believe that?

On 2023-08-14, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
> Kaz Kylheku <864-117-4973@kylheku.com> writes:
>> On 2023-08-14, Kenny McCormack <gazelle@shell.xmission.com> wrote:
>>> In article <87r0o6mqme.fsf@nosuchdomain.example.com>,
>>> Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>>>>scott@slp53.sl.home (Scott Lurndal) writes:
>>>>[...]
>>>>> Most programs in unix will accept '-?' or '-h' or some other flag
>>>>> to indicate that usage information is to be printed. Many utilities
>>>>> will print usage information if the input arguments are not valid.
>>>>
>>>>Most Unix programs don't use '-?' because '?' is a shell wildcard
>>>>character. If you happen to have files in the current directory named
>>>>"-x" and "-y", "myprogram -?" expands to "myprogram -x -y".
>>>
>>> Indeed - and this is one of the many reasons why insisting on an option
>>> (any option) to get help is a bad idea. Given that -? is kind of a
>>> standard in the Windows world, many programs that get ported over to
>>> Unix from Windows, will have this misfeature.
>>
>> Many command-line programs get ported to Unix from Windows?
>>
>> Why don't they adjust their conventions?
>>
>> /X /Y /Z /? is another convention; that one is smarter.
>>
>> The system installation can arrange for the first three not
>> to be paths, and for /? not to match anything due to there
>> not being a one-character item in the root dir.
>
> Having a program misbehave because there happens to be a one-character
> item in the root directory is a bad idea.

But the problem of wildcard expansion producing that by accident
seems very improbable.

The * pattern won't expand to anything that has a leading slash. You
would have to explicitly do

utility /*

where /* expands to a set of paths the first of which (and possibly
others) look like an option. I don't think that's super common
compared to *.

This seems like less of a threat than

utility *

expanding to arguments that look like - options.

I would also disallow clumping options like /abc instead
of /a /b /c, so the clashing namespace is just one character.

Kaz Kylheku <864-117-4973@kylheku.com> writes:

> On 2023-08-14, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>> Kaz Kylheku <864-117-4973@kylheku.com> writes:
>>> On 2023-08-14, Kenny McCormack <gazelle@shell.xmission.com> wrote:
>>>> In article <87r0o6mqme.fsf@nosuchdomain.example.com>,
>>>> Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>>>>>scott@slp53.sl.home (Scott Lurndal) writes:
>>>>>[...]
>>>>>> Most programs in unix will accept '-?' or '-h' or some other flag
>>>>>> to indicate that usage information is to be printed. Many utilities
>>>>>> will print usage information if the input arguments are not valid.
>>>>>
>>>>>Most Unix programs don't use '-?' because '?' is a shell wildcard
>>>>>character. If you happen to have files in the current directory named
>>>>>"-x" and "-y", "myprogram -?" expands to "myprogram -x -y".
>>>>
>>>> Indeed - and this is one of the many reasons why insisting on an option
>>>> (any option) to get help is a bad idea. Given that -? is kind of a
>>>> standard in the Windows world, many programs that get ported over to
>>>> Unix from Windows, will have this misfeature.
>>>
>>> Many command-line programs get ported to Unix from Windows?
>>>
>>> Why don't they adjust their conventions?
>>>
>>> /X /Y /Z /? is another convention; that one is smarter.
>>>
>>> The system installation can arrange for the first three not
>>> to be paths, and for /? not to match anything due to there
>>> not being a one-character item in the root dir.
>>
>> Having a program misbehave because there happens to be a one-character
>> item in the root directory is a bad idea.
>
> But the problem of wildcard expansion producing that by accident
> seems very improbable.
>
> The * pattern won't expand to anything that has a leading slash. You
> would have to explicitly do
>
> utility /*
>
> where /* expands to a set of paths the first of which (and possibly
> others) look like an option.

But you are suggesting users type /? for help. That could match a file
and produce almost any other flag as a result. I suspect that was
Keith's main concern.

> I would also disallow clumping options like /abc instead
> of /a /b /c, so the clashing namespace is just one character.

You could (as world king) disallow combining flags with the '-'
convention as well. You /have/ to with the '/' convention which makes
it /less/ smart in my book.

--
Ben.

> .... Given that -? is kind of a
> standard in the Windows world, many programs that get ported over to
> Unix from Windows, will have this misfeature.
>

Command line programs ported from Windows to Unix !!!!! Sounds like an
oxymoron to me :-)

Do you have some in mind?

On 14/08/2023 16:41, Scott Lurndal wrote:
> gazelle@shell.xmission.com (Kenny McCormack) writes:
>> In article <874jl1j4rh.fsf@bsb.me.uk>,
>> Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
>> ...
>>> Agreed. And newer programs will follow the ancient convention. The
>>> distinction, it seems to me, is not age but purpose. If you can easily
>>> see a program being used in a pipeline, it should silently read stdin,
>>
>> No. As I mentioned earlier, if "cat" (et al) was being designed today, it
>> wouldn't work like that.
>
> Why do you believe that?
>

$ cat a.c b.c - <c.c >abc.c

What's not to love?

Richard Harnden <richard.nospam@gmail.com> writes:
>On 14/08/2023 16:41, Scott Lurndal wrote:
>> gazelle@shell.xmission.com (Kenny McCormack) writes:
>>> In article <874jl1j4rh.fsf@bsb.me.uk>,
>>> Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
>>> ...
>>>> Agreed. And newer programs will follow the ancient convention. The
>>>> distinction, it seems to me, is not age but purpose. If you can easily
>>>> see a program being used in a pipeline, it should silently read stdin,
>>>
>>> No. As I mentioned earlier, if "cat" (et al) was being designed today, it
>>> wouldn't work like that.
>>
>> Why do you believe that?
>>
>
>$ cat a.c b.c - <c.c >abc.c
>
>What's not to love?

Exactly.

$ nroff -mm docbody.mm | cat docheader.txt - doctrailer.txt > document

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.

Cheers,
Gary B-)

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.

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

Don't forget about users who need to deal with files with arbitrary
names, and who often find it convenient to `cd` to a directory
containing such files.

[...]

--
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 */

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.

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

The usual example of an ‘admin script’ that has to deal with bizarre
user-created file is a /tmp cleaner. Not quite the same issue as we
started with here but depending on how experienced the script author is
there is plenty of room for accidental or adversarial mischief.

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

In article <wwvleeceobt.fsf@LkoBDZeT.terraraq.uk>,
Richard Kettlewell <invalid@invalid.invalid> 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.

This is a situation where using a GUI file manager (Windows Explorer
equivalent - whatever they are calling it in Unix/Linux these days).
Weirdly named files are no problem to delete from a GUI, since no shell is
involved.

--
If Jeb is Charlie Brown kicking a football-pulled-away, Mitt is a '50s
housewife with a black eye who insists to her friends the roast wasn't
dry.

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.

In comp.unix.programmer Gary R. Schmidt <grschmidt@acm.org> wrote:
> On 15/08/2023 01:14, Kalevi Kolttonen wrote:
> Ahah! You don't have users, do you?

No, I no longer have users. However, I used to have
50 000 - 60 000 users, but only a tiny minority
of them had Unix shell access. The vast majority
was email users.

I certainly never ever encountered anyone
with filename or email folder name being '-'.

> No doubt you also don't encounter filenames with
> spaces in them, or carriage returns, or other
> garbage.

That is a terrible and unjustified comparison
as filenams with spaces are very common indeed.

The "problem" of having '-' as a filename is
a complete non-issue that only has theoretical
interest. On Unix, no matter which stdin
convention you choose, you run the risk of
someone having that convention as a filename.

On Unix, it used to be the case that only
NUL-characters and '/' were out of question. I
suppose some filesystems place more restrictions
on filenames nowadays.

br,
KK

On Monday, August 14, 2023 at 8:21:49 PM UTC+3, Jim Jackson wrote:
> > .... Given that -? is kind of a
> > standard in the Windows world, many programs that get ported over to
> > Unix from Windows, will have this misfeature.
> >
> Command line programs ported from Windows to Unix !!!!! Sounds like an
> oxymoron to me :-)
>
> Do you have some in mind?

Probably many thousands of programs every year. Almost exclusively in-house
stuff so you will never see them.

I ported one less than a year ago. Would have ported another one if had
time and wasn't lazy.

On 8/15/23 16:30, Kalevi Kolttonen wrote:
> On Unix, it used to be the case that only
> NUL-characters and '/' were out of question. I
> suppose some filesystems place more restrictions
> on filenames nowadays.

There are still no restriction on file names. It`s only a problem of the
program. If it expects a file name as input, it has to test if the
argument passed is - in which case it reads from stdin. And, usually,
this works even if the file system has in the current directory a file
named -

To use the file - you should pass it to the program as ./-

Ciao
Giovanni
--
A computer is like an air conditioner,
it stops working when you open Windows.
< https://giovanni.homelinux.net/ >

In article <ubg4no$8kb$1@milena.home.net.it>,
Giovanni <gfalzoni@inwind.it> wrote:
>On 8/15/23 16:30, Kalevi Kolttonen wrote:
>> On Unix, it used to be the case that only
>> NUL-characters and '/' were out of question. I
>> suppose some filesystems place more restrictions
>> on filenames nowadays.
>
>There are still no restriction on file names. It`s only a problem of the
>program. If it expects a file name as input, it has to test if the
>argument passed is - in which case it reads from stdin. And, usually,
>this works even if the file system has in the current directory a file
>named -
>
>To use the file - you should pass it to the program as ./-

Yes, as noted, you know that.

And I know that.

And even Kalevi knows that.

But do they know that???

--
The randomly chosen signature file that would have appeared here is more than 4
lines long. As such, it violates one or more Usenet RFCs. In order to remain
in compliance with said RFCs, the actual sig can be found at the following URL:
http://user.xmission.com/~gazelle/Sigs/Aspergers

kalevi@kolttonen.fi (Kalevi Kolttonen) writes:
> The "problem" of having '-' as a filename is
> a complete non-issue that only has theoretical
> interest. On Unix, no matter which stdin
> convention you choose, you run the risk of
> someone having that convention as a filename.

Not everything is a valid filename in unix. If you can exclude the
possibility of accepting a directory, then you could have adopted
something that could only be a directory as the placeholder, such as
'.', or '/', or '-/', or .... Ooof, technically you could use '',
as that's a forbidden filename too, but I'm not suggesting that.

> On Unix, it used to be the case that only
> NUL-characters and '/' were out of question. I
> suppose some filesystems place more restrictions
> on filenames nowadays.

There are many contexts where certain characters have special meanings,
and so it makes sense to avoid them in filenames (colons spring to mind,
but of course some shell characters). However, sense has never been a
proven property of the modern computer user. At least the order of
command processing is mostly sane, so that you can't use malicious
filenames to inject shell metacharacters into commandlines, it's only
the programs being executed that could get confused by what they
receive.

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/

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.

br,
KK

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.

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.