Piping to stdin

[Spiros Bousbouras]

[ Followup-To: comp.unix.programmer ]

On Sun, 13 Aug 2023 06:42:17 -0700 (PDT)

On Unix-lke systems, what is the convention for putting a program into a
mode where it accepts input from stdin?
Where the user invokes it directly, he'll normally want input from a file. So
the normal invocation would be
myprogram myinput.txt
But if he just types "myprogram" it should display brief help text. So we
can't omit the filename to make the program read from stdin.

I would use a -h option for help text and with no arguments it should read
from stdin .

So do you pass an option
myprogram -stdin
or what is the normal way of solving this?

- (a single dash) as argument. Even if the programme accepts multiple file
name arguments , a single dash among those means "read from stdin".

[Spiros Bousbouras]

On Sun, 13 Aug 2023 07:07:55 -0700 (PDT)

Post by Spiros Bousbouras
[ Followup-To: comp.unix.programmer ]
On Sun, 13 Aug 2023 06:42:17 -0700 (PDT)

On Unix-lke systems, what is the convention for putting a program into a
mode where it accepts input from stdin?
Where the user invokes it directly, he'll normally want input from a file. So
the normal invocation would be
myprogram myinput.txt
But if he just types "myprogram" it should display brief help text. So we
can't omit the filename to make the program read from stdin.

[...]

Post by Spiros Bousbouras

So do you pass an option
myprogram -stdin
or what is the normal way of solving this?

- (a single dash) as argument. Even if the programme accepts multiple file
name arguments , a single dash among those means "read from stdin".

So conventionally the file name is "-"?

Yes.

[Kenny McCormack]

In article <***@bongo-ra.co>,
Spiros Bousbouras <***@gmail.com> wrote:
...

So conventionally the file name is "-"?

Yes.

Yes, but, as indicated, it is just that - a convention. The program has to
recognize it, and act accordingly. Note, incidentally, that it raises the
question of "What if the user actually has a file named '-' ?"

By the way, I wish to point out that, despite all the passion some here
have argued with, the idea that a program *must* read stdin if no args are
given, is a) not absolute and b) basically old-fashioned. The newer model
is, as Malcolm would like it to be, that running a program with no args
*should* generate a usage message. Among other things, the user should not
have to guess what the "help" option is. Is it -h, -?, --help, or something
else???

For example, consider "cat". As it is, if you run cat with no args, it
will copy stdin to stdout. That's the old-fashioned way - and, of course
that can't be changed (i.e., fixed) now, because of all the existing code
(scripts) that depend on it (and would break if it were changed). But if
"cat" were being designed today, it would probably require a '-' to make it
read stdin and, if run with no args, would display a usage message.

Note, incidentally, that if you run "cat" with no args from a shell prompt,
it will look like your computer has crashed, and you may be reaching for
the power cord. Programs can handle this by using the isatty() function;
and if stdin is a tty, can, at least, issue a prompt before reading from
stdin. Or, of course, they can throw a flag on the play and tell the user
that there is no point in reading input from the terminal (which is, in
fact, pretty much true for most programs). Some (but not many)
well-conceived modern programs do this.

[Kaz Kylheku]

Post by Kenny McCormack
...

So conventionally the file name is "-"?

Yes.

Yes, but, as indicated, it is just that - a convention. The program has to
recognize it, and act accordingly. Note, incidentally, that it raises the
question of "What if the user actually has a file named '-' ?"

Then they write a path to reference it which doesn't look like "-",
such as "./-".

[Kenny McCormack]

Post by Kaz Kylheku

Post by Kenny McCormack
...

So conventionally the file name is "-"?

Yes.

Yes, but, as indicated, it is just that - a convention. The program has to
recognize it, and act accordingly. Note, incidentally, that it raises the
question of "What if the user actually has a file named '-' ?"

Then they write a path to reference it which doesn't look like "-",
such as "./-".

You know that - and I know that - but do they know that?

[Kalevi Kolttonen]

Post by Kenny McCormack
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

[Gary R. Schmidt]

Post by Kalevi Kolttonen

Post by Kenny McCormack
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-)

[Kaz Kylheku]

Post by Gary R. Schmidt

Post by Kalevi Kolttonen

Post by Kenny McCormack
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.

[Keith Thompson]

Post by Kaz Kylheku

Post by Gary R. Schmidt

Post by Kalevi Kolttonen

Post by Kenny McCormack
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.

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

[...]

[Richard Kettlewell]

Post by Kaz Kylheku

Post by Gary R. Schmidt
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.

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

Post by Kaz Kylheku
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.

[Kenny McCormack]

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

[David Brown]

Post by Richard Kettlewell

Post by Kaz Kylheku

Post by Gary R. Schmidt
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.

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

[Richard Harnden]

Post by David Brown

Post by Richard Kettlewell

Post by Kaz Kylheku

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.

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

[Scott Lurndal]

Post by Richard Harnden

Post by David Brown

Post by Kaz Kylheku

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.

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

[vallor]

On Tue, 15 Aug 2023 19:50:44 +0100, Richard Harnden

Post by Richard Harnden

Post by David Brown

Post by Richard Kettlewell

Post by Kaz Kylheku

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.

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

[Richard Kettlewell]

Post by David Brown

Post by Richard Kettlewell
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.

[Scott Lurndal]

Post by Richard Kettlewell

Post by David Brown

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.

[Kenny McCormack]

Post by Scott Lurndal

Post by Richard Kettlewell

Post by David Brown

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.

[Spiros Bousbouras]

On Wed, 16 Aug 2023 17:37:55 GMT

Post by Scott Lurndal

Post by Richard Kettlewell

Post by David Brown

Post by Richard Kettlewell
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.

[Kaz Kylheku]

Post by Spiros Bousbouras
On Wed, 16 Aug 2023 17:37:55 GMT

Post by Scott Lurndal

Post by Richard Kettlewell

Post by David Brown

Post by Richard Kettlewell
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.

[Kaz Kylheku]

Post by Kaz Kylheku

Post by Spiros Bousbouras
On Wed, 16 Aug 2023 17:37:55 GMT

Post by Scott Lurndal

Post by Richard Kettlewell

Post by David Brown

Post by Richard Kettlewell
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.

[Keith Thompson]

Post by Scott Lurndal

Post by Richard Kettlewell

Post by David Brown

Post by Richard Kettlewell
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).

[Geoff Clare]

Post by Keith Thompson
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).

POSIX does specify that "rm -- -r" removes a file called -r.

Almost all the utilities have a statement under OPTIONS that they
conform to XBD 12.2 Utility Syntax Guidelines (in some cases with
exceptions for specific individual guidelines). The requirement to
support "--" is guideline 10.

[Keith Thompson]

Post by Geoff Clare

Post by Keith Thompson
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).

POSIX does specify that "rm -- -r" removes a file called -r.
Almost all the utilities have a statement under OPTIONS that they
conform to XBD 12.2 Utility Syntax Guidelines (in some cases with
exceptions for specific individual guidelines). The requirement to
support "--" is guideline 10.

Quite right, I sit corrected.

https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap12.html#tag_12_02

[Phil Carmody]

Post by Scott Lurndal

Post by Richard Kettlewell

Post by David Brown

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

[James Kuyper]

...

Post by Richard Kettlewell

Post by Kaz Kylheku
- 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.

[David Brown]

Post by James Kuyper
...

Post by Richard Kettlewell

Post by Kaz Kylheku
- 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.

[Joe Pfeiffer]

Post by Kaz Kylheku

Post by Gary R. Schmidt

Post by Kalevi Kolttonen

Post by Kenny McCormack
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.

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

[Richard Harnden]

Post by Joe Pfeiffer

Post by Kaz Kylheku

Post by Gary R. Schmidt

Post by Kalevi Kolttonen

Post by Kenny McCormack
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.

- 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

[Phil Carmody]

Post by Richard Harnden

Post by Joe Pfeiffer

Post by Kaz Kylheku

Post by Gary R. Schmidt

Post by Kalevi Kolttonen

Post by Kenny McCormack
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.

- 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

[Kalevi Kolttonen]

Post by Gary R. Schmidt
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 '-'.

Post by Gary R. Schmidt
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

[Giovanni]

Post by Kalevi Kolttonen
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

[Kenny McCormack]

Post by Giovanni

Post by Kalevi Kolttonen
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???

[Kalevi Kolttonen]

Post by Kenny McCormack
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

[M***@dastardlyhq.com]

On Tue, 15 Aug 2023 16:12:19 -0000 (UTC)

Post by Kalevi Kolttonen

Post by Kenny McCormack
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.

[Kalevi Kolttonen]

Post by M***@dastardlyhq.com
On Tue, 15 Aug 2023 16:12:19 -0000 (UTC)

Post by Kalevi Kolttonen

Post by Kenny McCormack
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

[M***@dastardlyhq.com]

On Tue, 15 Aug 2023 16:22:16 -0000 (UTC)

Post by Kalevi Kolttonen

Post by M***@dastardlyhq.com
On Tue, 15 Aug 2023 16:12:19 -0000 (UTC)

Post by Kalevi Kolttonen

Post by Kenny McCormack
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.

[Kalevi Kolttonen]

Post by M***@dastardlyhq.com
They both cause problems.

So do nuclear bombs and fentynyl, yet they have
not enough in common to make a sensible comparison
between them.

Similar reasoning applies to filenames with spaces
and the '-' stdin convention. Many people like
the former and are justified in doing so, but
nobody has the desire to use '-' as a filename.

I am tired of making this obvious point over and
over, so if it does not sink in now, I have to
give up.

br,
KK

[Scott Lurndal]

Post by Kalevi Kolttonen

Post by M***@dastardlyhq.com
They both cause problems.

So do nuclear bombs and fentynyl, yet they have
not enough in common to make a sensible comparison
between them.
Similar reasoning applies to filenames with spaces
and the '-' stdin convention. Many people like
the former and are justified in doing so, but
nobody has the desire to use '-' as a filename.
I am tired of making this obvious point over and
over, so if it does not sink in now, I have to
give up.

It's like arguments about how many angels can dance
on the point of a pin - the use of a single hyphen
to denote stdin will _never_ change, it is pointless
to assume otherwise.

[Kaz Kylheku]

Post by M***@dastardlyhq.com
On Tue, 15 Aug 2023 16:12:19 -0000 (UTC)

Post by Kalevi Kolttonen

Post by Kenny McCormack
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 ...

[Phil Carmody]

Post by M***@dastardlyhq.com
On Tue, 15 Aug 2023 16:12:19 -0000 (UTC)

Post by Kalevi Kolttonen

Post by Kenny McCormack
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

[M***@dastardlyhq.com]

On Tue, 15 Aug 2023 23:32:22 +0300

Post by Phil Carmody

Post by M***@dastardlyhq.com
On Tue, 15 Aug 2023 16:12:19 -0000 (UTC)

Post by Kalevi Kolttonen

Post by Kenny McCormack
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.

Post by Phil Carmody
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.

Post by Phil Carmody
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

[Phil Carmody]

Post by M***@dastardlyhq.com
On Tue, 15 Aug 2023 23:32:22 +0300

Post by Phil Carmody

Post by M***@dastardlyhq.com
On Tue, 15 Aug 2023 16:12:19 -0000 (UTC)

Post by Kalevi Kolttonen

Post by Kenny McCormack
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.

Post by Phil Carmody
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.

Post by Phil Carmody
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.
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

[Geoff Clare]

Post by Phil Carmody

Post by M***@dastardlyhq.com
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.
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?

They don't have to: they can configure the filesystem that contains
their home directory to be properly case sensitive.

I have access to an ancient MacBook which is configured that way:

$ uname -sr
Darwin 15.4.0
$ touch HELLO
$ ls hello
ls: hello: No such file or directory
$ ls H*
HELLO
$ ls h*
ls: h*: No such file or directory

[M***@dastardlyhq.com]

On Thu, 17 Aug 2023 13:49:49 +0100

Post by M***@dastardlyhq.com

Post by Phil Carmody

Post by M***@dastardlyhq.com
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.

Post by Phil Carmody

Post by M***@dastardlyhq.com
Hopeless.
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?

They don't have to: they can configure the filesystem that contains
their home directory to be properly case sensitive.

You can, but it can break a lot of programs that expect case insensitivity.

[Kenny McCormack]

In article <***@fatphil.org>,
Phil Carmody <pc+***@asdf.org> wrote:
...

Post by Phil Carmody

Post by M***@dastardlyhq.com
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?

Kinda hate to disagree with ya there, but running Linux on Apple hardware
is like buying a BMW, ripping out the engine, and changing it into a go-kart.

Now, before you think I'm some Apple Fanboy, let me assure you that just
the opposite is true. I run all Linux, but I consider it wrong to pay more
than $100 for the box upon which I run Linux. That's why I'm all Raspberry
Pi nowadays.

But if you've paid Apple's exhorbitant fee to buy their hardware, then you
might as well be running their OS. I don't want to have to dot all the I's
and cross all the T's on this, but I assume you get what I mean. If you
like Linux, you should not be paying Apple prices for your hardware.

Or, to put it another way, Apple stuff (hardware and software) is for
people who like that sort of thing. And they do indeed like it.

By the way, the car analogy is not accidental. I believe that the more you
pay for a car, the more problems you will have with it. You are literally
paying for the problems. And again, there are people who like that. So,
again, paying lots for a car is for people who like that sort of thing.
And they do indeed like it.

[Phil Carmody]

Post by Kenny McCormack
...

Post by Phil Carmody

Post by M***@dastardlyhq.com
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?

Kinda hate to disagree with ya there, but running Linux on Apple hardware
is like buying a BMW, ripping out the engine, and changing it into a go-kart.
Now, before you think I'm some Apple Fanboy, let me assure you that just
the opposite is true. I run all Linux, but I consider it wrong to pay more
than $100 for the box upon which I run Linux. That's why I'm all Raspberry
Pi nowadays.
But if you've paid Apple's exhorbitant fee to buy their hardware, then you
might as well be running their OS.

Hahahah. Nah, never paid a penny. It was a "sponsorship" from Apple.
Top of the range kit at the time too. All I had to do was write fast
code and not insult them in public. Managed for several years.

Oh - my code ran faster under linux than OSX. The apple compiler seemed
to never want to use all 32 of the FP registers (and, more bizarrely,
the register it would mysteriously forget existed wasn't always the same
one). I later worked for Freescale and had access to their internal
tools, and could see how good or bad a job the various compilers were at
keeping the pipelines full, and it was clear that Apple weren't as smart
as they thought they were.

Phil

[David Brown]

Post by Kenny McCormack
...

Post by Phil Carmody

Post by M***@dastardlyhq.com
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?

Kinda hate to disagree with ya there, but running Linux on Apple hardware
is like buying a BMW, ripping out the engine, and changing it into a go-kart.
Now, before you think I'm some Apple Fanboy, let me assure you that just
the opposite is true. I run all Linux, but I consider it wrong to pay more
than $100 for the box upon which I run Linux. That's why I'm all Raspberry
Pi nowadays.
But if you've paid Apple's exhorbitant fee to buy their hardware, then you
might as well be running their OS. I don't want to have to dot all the I's
and cross all the T's on this, but I assume you get what I mean. If you
like Linux, you should not be paying Apple prices for your hardware.
Or, to put it another way, Apple stuff (hardware and software) is for
people who like that sort of thing. And they do indeed like it.

I disagree completely.

Apple made good quality hardware, with a style that many people like.
(I personally do not, and have never owned anything Apple.) Sure, you
pay a premium for it, but that's the case for a lot of hardware - if you
draw a graph of processor speed against processor price, you'll easily
see a point where you pay a lot of extra cash for a very small increase
in price. Yet for some people, that large increase is worth it.

So your Apple hardware might be twice the price for a 10% thinner and
lighter laptop. But if that's what you want, go for it - just as it is
fine to want far lower prices and accept slower or weaker hardware.

Then if someone decides that they want the Apple hardware, they've got
the money, they have no moral qualms about paying the high markup Apple
charges (some people have strong opinions about that kind of thing),
that's fine - they've bought the Apple hardware.

And if they decide that they prefer Linux (or Windows) to MacOS, then
installing their preferred system makes the system better - it increases
the value to them. It would be absurd to use an OS that is inferior (at
least in that person's view) just because they had paid for it! You
would not expect a Linux fan to use the Windows installation that comes
with most off-the-shelf PC's - why would you expect them to use MacOS ?


Case in point - Linus Torvalds used a MacBook running Linux as his main
PC for a while, because the hardware (the screen in particular) was
better than alternative laptops.

[M***@dastardlyhq.com]

On Thu, 17 Aug 2023 14:57:44 +0300

Post by M***@dastardlyhq.com

Post by M***@dastardlyhq.com
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.

Post by M***@dastardlyhq.com
Hopeless.
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

It is, its a cut and paste from the terminal.

Post by M***@dastardlyhq.com
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?

I bought a Mac because I wanted a unix box that I could just switch on and
get coding rather than mess about installing some linux distro and hope the
bits all work. Plus MacOS has a bonus of lots of high quality apps on the
App Store. Though tbh if Solaris workstations were still a thing I'd have bought
one of them instead.

[Kaz Kylheku]

Post by M***@dastardlyhq.com
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.

[M***@dastardlyhq.com]

On Thu, 17 Aug 2023 13:52:23 -0000 (UTC)

Post by Kaz Kylheku

Post by M***@dastardlyhq.com
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.

Ok, there are a couple of exceptions. Point still stands.

Post by Kaz Kylheku
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.

But they don't have to and when UTF8 filenames get used things can get messy
on non UTF8 terminals.

[Keith Thompson]

Post by Kaz Kylheku

Post by M***@dastardlyhq.com
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.

https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03.html#tag_03_282

A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
a b c d e f g h i j k l m n o p q r s t u v w x y z
0 1 2 3 4 5 6 7 8 9 . _ -

[David Brown]

Post by Kaz Kylheku

Post by M***@dastardlyhq.com
Any character from 0-255 is allowed in unix filenames but only an idiot would
use spaces and non printing characters.

Only an idiot would think one rule fits all use-cases.

Post by Kaz Kylheku
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.

It is even wiser to use characters that are appropriate for the task in
hand.

If you are making software that will be shared amongst a wide variety of
systems, stick to ASCII letters, digits, and underscore - that will work
on everything, including Windows.

If you are writing a document in Thai that will be read by Thai speakers
on Thai computers, name the document in Thai using Thai script.

It's not hard to handle "complicated" filenames from the command line,
outside a few pathological cases (like "-"). Sensible filenames are
fine, even with spaces, brackets, or non-ASCII letters. If those
features are helpful to the main use of the names for the files in
question, use them. If they are unhelpful, don't use them.

Thus it makes sense to avoid inconvenient characters in the names and
paths of programs, and you'll very rarely want them in program source
code names or directories. But they are common and useful for things
like document filenames.

[Ben Bacarisse]

Post by M***@dastardlyhq.com
On Tue, 15 Aug 2023 23:32:22 +0300

Post by Phil Carmody

Post by M***@dastardlyhq.com
On Tue, 15 Aug 2023 16:12:19 -0000 (UTC)

Post by Kalevi Kolttonen

Post by Kenny McCormack
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.

To some extent it depends on the file system, and to some extent it's
down to the kernel, but I don't know of any Unix/FS combination that
permits 0 (null) bytes in file names. I can't see how it could work.

And almost all file systems will prohibit the use of / in a file name,
though I've heard you can trick NFS into taking it.

Some file systems (depending on mount options) can have complex rules
such as rejecting any name with an invalid UTF-8 sequence.

[Phil Carmody]

Post by Ben Bacarisse
Some file systems (depending on mount options) can have complex rules
such as rejecting any name with an invalid UTF-8 sequence.

Oooh, now I'm tempted to name files in Latin-1, to deliberately break
filesystems that make such assumptions!

Phil

[Oğuz]

Post by Phil Carmody

Post by Ben Bacarisse
Some file systems (depending on mount options) can have complex rules
such as rejecting any name with an invalid UTF-8 sequence.

Oooh, now I'm tempted to name files in Latin-1, to deliberately break
filesystems that make such assumptions!

Be careful with that attitude. The "memory-safe" sudo replacement
doesn't support non-UTF-8 input either:

https://github.com/memorysafety/sudo-rs/issues/213

[M***@dastardlyhq.com]

On Sat, 19 Aug 2023 16:15:32 +0300

Post by Oğuz

Post by Phil Carmody

Post by Ben Bacarisse
Some file systems (depending on mount options) can have complex rules
such as rejecting any name with an invalid UTF-8 sequence.

Oooh, now I'm tempted to name files in Latin-1, to deliberately break
filesystems that make such assumptions!

Be careful with that attitude. The "memory-safe" sudo replacement

Whats memory unsafe about sudo?

[Scott Lurndal]

Post by M***@dastardlyhq.com
On Sat, 19 Aug 2023 16:15:32 +0300

Post by Oğuz

Post by Phil Carmody

Post by Ben Bacarisse
Some file systems (depending on mount options) can have complex rules
such as rejecting any name with an invalid UTF-8 sequence.

Oooh, now I'm tempted to name files in Latin-1, to deliberately break
filesystems that make such assumptions!

Be careful with that attitude. The "memory-safe" sudo replacement

Whats memory unsafe about sudo?

https://www.cisa.gov/news-events/alerts/2021/02/02/sudo-heap-based-buffer-overflow-vulnerability-cve-2021-3156

[M***@dastardlyhq.com]

On Sun, 20 Aug 2023 17:24:46 GMT

Post by Scott Lurndal

Post by M***@dastardlyhq.com
On Sat, 19 Aug 2023 16:15:32 +0300

Post by Oğuz

Post by Phil Carmody

Post by Ben Bacarisse
Some file systems (depending on mount options) can have complex rules
such as rejecting any name with an invalid UTF-8 sequence.

Oooh, now I'm tempted to name files in Latin-1, to deliberately break
filesystems that make such assumptions!

Be careful with that attitude. The "memory-safe" sudo replacement

Whats memory unsafe about sudo?

https://www.cisa.gov/news-events/alerts/2021/02/02/sudo-heap-based-buffer-overf
low-vulnerability-cve-2021-3156

One bug in one version doesn't make it generally unsafe.

[Rainer Weikusat]

Post by M***@dastardlyhq.com
On Sat, 19 Aug 2023 16:15:32 +0300

Post by Oğuz

Post by Phil Carmody

Post by Ben Bacarisse
Some file systems (depending on mount options) can have complex rules
such as rejecting any name with an invalid UTF-8 sequence.

Oooh, now I'm tempted to name files in Latin-1, to deliberately break
filesystems that make such assumptions!

Be careful with that attitude. The "memory-safe" sudo replacement

Whats memory unsafe about sudo?

It's not written in a language whose extremely complicate runtime system
that's conjectured to be bug free in this respect by Really Wishful
Thinking[tm] is supposed to prevent simple memory access errors C
supports.

[Kenny McCormack]

In article <***@doppelsaurus.mobileactivedefense.com>,
Rainer Weikusat <***@talktalk.net> wrote:
...

It's not written in a language whose extremely complicate runtime
system that's conjectured to be bug free in this respect by Really
Wishful Thinking[tm] is supposed to prevent simple memory access errors
C supports.

What language was this quoted paragraph written in?

Preumably one in which word order doesn't matter.

[Scott Lurndal]

Post by Kenny McCormack
...

It's not written in a language whose extremely complicate runtime
system that's conjectured to be bug free in this respect by Really
Wishful Thinking[tm] is supposed to prevent simple memory access errors
C supports.

What language was this quoted paragraph written in?
Preumably one in which word order doesn't matter.

Word order in German and English don't always agree.

Basically he is saying, somewhat mockingly, that because it is
not written in Rust, sudo written in C is inherently memory unsafe.

[Kenny McCormack]

Post by Scott Lurndal

Post by Kenny McCormack
...

It's not written in a language whose extremely complicate runtime
system that's conjectured to be bug free in this respect by Really
Wishful Thinking[tm] is supposed to prevent simple memory access errors
C supports.

What language was this quoted paragraph written in?
Preumably one in which word order doesn't matter.

Word order in German and English don't always agree.
Basically he is saying, somewhat mockingly, that because it is
not written in Rust, sudo written in C is inherently memory unsafe.

OK, thanks.

I am glad that you were able to intuit that "Rust" was "the other language"
involved in the comparison.

[Rainer Weikusat]

Post by Kenny McCormack

Post by Scott Lurndal

Post by Kenny McCormack
...

It's not written in a language whose extremely complicate runtime
system that's conjectured to be bug free in this respect by Really
Wishful Thinking[tm] is supposed to prevent simple memory access errors
C supports.

What language was this quoted paragraph written in?
Preumably one in which word order doesn't matter.

Word order in German and English don't always agree.
Basically he is saying, somewhat mockingly, that because it is
not written in Rust, sudo written in C is inherently memory unsafe.

OK, thanks.
I am glad that you were able to intuit that "Rust" was "the other language"
involved in the comparison.

That's pretty obvious from the

,----
| Be careful with that attitude. The "memory-safe" sudo replacement
| doesn't support non-UTF-8 input either:
|
| https://github.com/memorysafety/sudo-rs/issues/213
`----

upthread. Rust is conjectured to be memory safe because people using it
really want to believe that the Rust runtime - some orders of magnitude
more complicated than a real lot of C programs - has not such bugs.

[Kenny McCormack]

In article <***@doppelsaurus.mobileactivedefense.com>,
Rainer Weikusat <***@talktalk.net> wrote:
...

Post by Rainer Weikusat
,----
| Be careful with that attitude. The "memory-safe" sudo replacement
|
| https://github.com/memorysafety/sudo-rs/issues/213
`----

That URL means nothing to me. But that's just me. Don't take it
personally.

[Rainer Weikusat]

Post by Kenny McCormack
...

Post by Rainer Weikusat
,----
| Be careful with that attitude. The "memory-safe" sudo replacement
|
| https://github.com/memorysafety/sudo-rs/issues/213
`----

That URL means nothing to me. But that's just me. Don't take it
personally.

In this case, I suggest one of two options

1) You'll try to memorize that rs commonly means Rust. Eg, it's usually
the extension used for Rust source files.

2) You'll ask your full-time carer to click on the link for you and read
the content of the page to you.

In either case, posting more lame flames into this groups for no
conceivable reason is not going to improve your understanding of
anything.

[Kenny McCormack]

blah, blah, blah

I told you not to take it personally, but what do you go and do?

All I can say is that I tried to help you and to steer you in the right
direction.

[Rainer Weikusat]

Post by Kenny McCormack

blah, blah, blah

I told you not to take it personally, but what do you go and do?

I'm principally interested in technical discussions, eg, about Rust and
memory safety, and sometimes motivated to try my hands at minimally
creative flames when people are trying to play the Most Importinant
Dickhead with the help of the usual boilerplate phrases.

[M***@dastardlyhq.com]

On Mon, 21 Aug 2023 01:26:36 GMT

Post by Scott Lurndal

Post by Kenny McCormack
...

It's not written in a language whose extremely complicate runtime
system that's conjectured to be bug free in this respect by Really
Wishful Thinking[tm] is supposed to prevent simple memory access errors
C supports.

What language was this quoted paragraph written in?
Preumably one in which word order doesn't matter.

Word order in German and English don't always agree.
Basically he is saying, somewhat mockingly, that because it is
not written in Rust, sudo written in C is inherently memory unsafe.

To do anything low level Rust has to disable memory protection (or whatever
they call it) anyway, so its no safer than C/C++ in these circumstances.

[Ben Bacarisse]

Post by Phil Carmody

Post by Ben Bacarisse
Some file systems (depending on mount options) can have complex rules
such as rejecting any name with an invalid UTF-8 sequence.

Oooh, now I'm tempted to name files in Latin-1, to deliberately break
filesystems that make such assumptions!

Why?

[Kalevi Kolttonen]

Post by Phil Carmody

Post by Ben Bacarisse
Some file systems (depending on mount options) can have complex rules
such as rejecting any name with an invalid UTF-8 sequence.

Oooh, now I'm tempted to name files in Latin-1, to deliberately break
filesystems that make such assumptions!

Why?

I suppose that was some kind of a joke.

Anyway, one cannot "break" those filesystems as the
invalid names are simply rejected. I am not 100%
sure but ZFS might be an instance of such a filesystem.

br,
KK

[Kenny McCormack]

Post by M***@dastardlyhq.com
On Tue, 15 Aug 2023 16:12:19 -0000 (UTC)

Post by Kalevi Kolttonen

Post by Kenny McCormack
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.

(I happened to be re-reading this 1 year old thread, so thought I'd add a
post to it)

Two comments about spaces in filenames (and Windows vs. Unix):

1) Windows is actually quite a bit more restrictive about characters in
filenames than Unix. Which is a good thing. I've always thought
the "anything other than NUL and /" in Unix was a bad thing and
encouraged all manner of bad/malicious outcomes. Yet, there are
people (and I use the term loosely) who think otherwise.

2) Spaces in filenames are pretty much a necessity from the end-user
POV (but see below). Yes, it makes things hard for us on the admin
side of the game. I have always thought that the right answer is
to have both - a short name that is usable for the admin side of
the game and a long label that the user can work with. There are
two solutions of this nature that I like:
a) The "Extend a name" idea. Where you have short names at the
filesystem level, but then have a database linked to that
that allows the user to think that long, descriptive
filenames are supported.

A long long time ago, there was a DOS product called
"Extend a name" that did this. Also, 4DOS (and later
versions) does this.
b) The way VFAT does it (and NTFS emulates) - where, for any
file with a long name, there is an 8.3 filename (usually
with weird characters in the filename) as well, and either
filename is usable by programs. This is one place where I
think Windows really gets it right (and Unix could learn
from it).

[Richard Kettlewell]

Post by Kenny McCormack
1) Windows is actually quite a bit more restrictive about characters in
filenames than Unix. Which is a good thing. I've always thought
the "anything other than NUL and /" in Unix was a bad thing and
encouraged all manner of bad/malicious outcomes. Yet, there are
people (and I use the term loosely) who think otherwise.

The historical advantage of the free-for-all Unix approach is that
allowed flexibility in filename encoding. Today it’d work to say “UTF-8
only” (and maybe other restrictions) but that wasn’t always the case.
The original design has saved us from a bit of path dependency.

In the application-facing API (open, CreateFile, etc), the rule pretty
much has to be ‘anything goes’, because you may be dealing with a
‘foreign’ filesystem (e.g. via a network filesystem). I don’t want to be
unable to access an existing file just because two computers have
different sets of restrictions on filenames.

(I’ll be disappointed in extreme cases of course, e.g. filesystems that
permit ‘/’ in filenames, but the scale of the problem can be minimized.)

Post by Kenny McCormack
2) Spaces in filenames are pretty much a necessity from the end-user
POV (but see below). Yes, it makes things hard for us on the admin
side of the game.

I think the thing that makes it hard is not the spaces as such, but the
tooling that makes it inconvenient to handle them, which primarily means
Bourne shell parsing rules. The problem basically ceases to exist once
you’re outside the shell ecosystem.

The rest of Unix has evolved substantially since the 1970s but shell is
still stuck in this particular trap. It’s like we’re still making making
arrowheads out of flint but everything else from steel.

[M***@dastardlyhq.com]

On Sat, 31 Aug 2024 09:27:44 +0100

Post by Richard Kettlewell

Post by Kenny McCormack
2) Spaces in filenames are pretty much a necessity from the end-user
POV (but see below). Yes, it makes things hard for us on the admin
side of the game.

I think the thing that makes it hard is not the spaces as such, but the
tooling that makes it inconvenient to handle them, which primarily means
Bourne shell parsing rules. The problem basically ceases to exist once
you’re outside the shell ecosystem.
The rest of Unix has evolved substantially since the 1970s but shell is
still stuck in this particular trap. It’s like we’re still making making
arrowheads out of flint but everything else from steel.

When parsing is based around words on a line how else exactly would you expect
it to be done? Every language tokenises based in seperators so unless you
expect the shell to automagically figure out when a filename ends and the next
part of the command begins then I would suggest using quotes is a solution
thats worked for decades and works fine.

[Lawrence D'Oliveiro]

Post by Richard Kettlewell
(I’ll be disappointed in extreme cases of course, e.g. filesystems that
permit ‘/’ in filenames, but the scale of the problem can be minimized.)

The nice thing about Unicode is the alternatives it offers: so you can’t
use “/” in a filename, but you can use “∕” instead.

Post by Richard Kettlewell
I think the thing that makes it hard is not the spaces as such, but the
tooling that makes it inconvenient to handle them, which primarily means
Bourne shell parsing rules. The problem basically ceases to exist once
you’re outside the shell ecosystem.
The rest of Unix has evolved substantially since the 1970s but shell is
still stuck in this particular trap. It’s like we’re still making making
arrowheads out of flint but everything else from steel.

If you avoid newlines in filenames, Posix shells can cope with anything
else if you set “IFS=$'\n'”.

If you insist on wanting to accept those as well, then I don’t think Posix
is enough, but Bash does have facilities that help you cope.

[Lawrence D'Oliveiro]

Post by Lawrence D'Oliveiro
If you avoid newlines in filenames, Posix shells can cope with anything
else if you set “IFS=$'\n'”.

Sorry, no, it looks like the “$'...'” syntax for string literals is not
from Posix, it’s a Bash-ism.

I think it’s still possible to assign a newline to $IFS, it just takes a
bit more work.

[M***@dastardlyhq.com]

On Sat, 31 Aug 2024 05:57:12 -0000 (UTC)

Post by Kenny McCormack
2) Spaces in filenames are pretty much a necessity from the end-user

No they're not.

Post by Kenny McCormack
b) The way VFAT does it (and NTFS emulates) - where, for any
file with a long name, there is an 8.3 filename (usually
with weird characters in the filename) as well, and either
filename is usable by programs. This is one place where I
think Windows really gets it right (and Unix could learn
from it).

No, just no. The windows "solution" is a hideous hack only required for
backwards compatability.

[Phil Carmody]

Post by Kalevi Kolttonen

Post by Kenny McCormack
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

[Lew Pitcher]

Post by Phil Carmody

Post by Kalevi Kolttonen

Post by Kenny McCormack
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.

[Phil Carmody]

Post by Lew Pitcher

Post by Phil Carmody

Post by Kalevi Kolttonen

Post by Kenny McCormack
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/

[Lew Pitcher]

[snip]

Post by Phil Carmody

Post by Lew Pitcher

Post by Phil Carmody

Post by Kalevi Kolttonen
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. :-)

[Kaz Kylheku]

Post by Lew Pitcher
[snip]

Post by Phil Carmody

Post by Lew Pitcher

Post by Phil Carmody

Post by Kalevi Kolttonen
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?

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.

[Phil Carmody]

Post by Lew Pitcher
[snip]

Post by Phil Carmody

Post by Lew Pitcher

Post by Phil Carmody

Post by Kalevi Kolttonen
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?

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

[Ben Bacarisse]

Post by Kalevi Kolttonen
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.

[Phil Carmody]

Post by Kalevi Kolttonen
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.

Post by Kalevi Kolttonen
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

[Nuno Silva]

Post by Kenny McCormack
...

So conventionally the file name is "-"?

Yes.

Yes, but, as indicated, it is just that - a convention. The program has to
recognize it, and act accordingly. Note, incidentally, that it raises the
question of "What if the user actually has a file named '-' ?"
By the way, I wish to point out that, despite all the passion some here
have argued with, the idea that a program *must* read stdin if no args are
given, is a) not absolute and b) basically old-fashioned. The newer model
is, as Malcolm would like it to be, that running a program with no args
*should* generate a usage message. Among other things, the user should not
have to guess what the "help" option is. Is it -h, -?, --help, or something
else???

If you consider acceptable a convention of showing usage when no
arguments are given, then why not a convention on what to call the help
option?

I'd also argue that there's what should be a more uniform way to get
documentation on utilities: the online manual. Or (seeing this was from
comp.lang.c) is this also about running on systems where there might be
no such manual facility?

[Kenny McCormack]

[...]

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.

[Kaz Kylheku]

Post by Kenny McCormack

[...]

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.

[Phil Carmody]

Post by Kaz Kylheku

Post by Kenny McCormack

[...]

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.

So if I want to grep case-insensitively for whole words, and have line
numbers printed with the matched lines - in other words, on the unix
version I'm doing ``grep -win ...'' - should my system installation
arrange for /win to not be a path?

Phil

[Keith Thompson]

Post by Kaz Kylheku

Post by Kenny McCormack

[...]

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. (For example, on Cygwin I
often make /c a symlink to /cygdrive/c for convenience.)

Also, some shells, either by default or depending on options, will print
an error message if a wildcard fails to match.

[Kaz Kylheku]

Post by Keith Thompson

Post by Kaz Kylheku

Post by Kenny McCormack

[...]

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.

[Ben Bacarisse]

Post by Kaz Kylheku

Post by Keith Thompson

Post by Kaz Kylheku

Post by Kenny McCormack

[...]

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.

Post by Kaz Kylheku
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.

[Jim Jackson]

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

[Joe Pfeiffer]

Post by Spiros Bousbouras
[ Followup-To: comp.unix.programmer ]
On Sun, 13 Aug 2023 06:42:17 -0700 (PDT)

On Unix-lke systems, what is the convention for putting a program into a
mode where it accepts input from stdin?
Where the user invokes it directly, he'll normally want input from a file. So
the normal invocation would be
myprogram myinput.txt
But if he just types "myprogram" it should display brief help text. So we
can't omit the filename to make the program read from stdin.

I would use a -h option for help text and with no arguments it should read
from stdin .

No, the typical user will expect help text from just typing the command
name (notwithstanding ancient programs like cat). I typically treat no
args the same as -h

Post by Spiros Bousbouras

So do you pass an option
myprogram -stdin
or what is the normal way of solving this?

- (a single dash) as argument. Even if the programme accepts multiple file
name arguments , a single dash among those means "read from stdin".

Yes, this is what seems common.

[Spiros Bousbouras]

On Sun, 13 Aug 2023 21:26:59 -0600

Post by Joe Pfeiffer

Post by Spiros Bousbouras
[ Followup-To: comp.unix.programmer ]
On Sun, 13 Aug 2023 06:42:17 -0700 (PDT)

On Unix-lke systems, what is the convention for putting a program into a
mode where it accepts input from stdin?
Where the user invokes it directly, he'll normally want input from a file. So
the normal invocation would be
myprogram myinput.txt
But if he just types "myprogram" it should display brief help text. So we
can't omit the filename to make the program read from stdin.

I would use a -h option for help text and with no arguments it should read
from stdin .

No, the typical user will expect help text from just typing the command
name (notwithstanding ancient programs like cat). I typically treat no
args the same as -h

Not to mention grep , awk , sed , sort , bc , od , etc. Being "ancient"
means that their conventions are more firmly established so why would a
user expect something else ?

[Ben Bacarisse]

Post by Spiros Bousbouras
On Sun, 13 Aug 2023 21:26:59 -0600

Post by Joe Pfeiffer

Post by Spiros Bousbouras
[ Followup-To: comp.unix.programmer ]
On Sun, 13 Aug 2023 06:42:17 -0700 (PDT)

On Unix-lke systems, what is the convention for putting a program into a
mode where it accepts input from stdin?
Where the user invokes it directly, he'll normally want input from a file. So
the normal invocation would be
myprogram myinput.txt
But if he just types "myprogram" it should display brief help text. So we
can't omit the filename to make the program read from stdin.

I would use a -h option for help text and with no arguments it should read
from stdin .

No, the typical user will expect help text from just typing the command
name (notwithstanding ancient programs like cat). I typically treat no
args the same as -h

Not to mention grep , awk , sed , sort , bc , od , etc. Being "ancient"
means that their conventions are more firmly established so why would a
user expect something else ?

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,
but if that usage is rare, it should interpret '-' as a convention for
reading stdin.

For example, gcc on it's own complains, but

echo "int f() { return 1; }" | gcc -S -xc - -o -

works as expected.

[Kenny McCormack]

In article <***@bsb.me.uk>,
Ben Bacarisse <***@bsb.me.uk> wrote:
...

Post by Ben Bacarisse
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.

[Scott Lurndal]

Post by Kenny McCormack
...

Post by Ben Bacarisse
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?

[Richard Harnden]

Post by Scott Lurndal

Post by Kenny McCormack
...

Post by Ben Bacarisse
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?

[Scott Lurndal]

Post by Richard Harnden

Post by Scott Lurndal

Post by Kenny McCormack
...

Post by Ben Bacarisse
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