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.

So do you pass an option

myprogram -stdin

or what is the normal way of solving this?

[ Followup-To: comp.unix.programmer ]

On Sun, 13 Aug 2023 06:42:17 -0700 (PDT)
Malcolm McLean <malcolm.arthur.mclean@gmail.com> wrote:
> 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".

--
vlaho.ninja/prog

On Sunday, 13 August 2023 at 14:55:57 UTC+1, Spiros Bousbouras wrote:
> [ Followup-To: comp.unix.programmer ]
> On Sun, 13 Aug 2023 06:42:17 -0700 (PDT)
> Malcolm McLean <malcolm.ar...@gmail.com> wrote:
> > 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 .
>
That's unacceptable to me. My users will expect that when they see a program
and type the name, it will either launch a GUI or print out. a brief message
saying what the program is and what it does.
>
> > 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 "-"?

On 13/08/2023 15:07, Malcolm McLean wrote:
> On Sunday, 13 August 2023 at 14:55:57 UTC+1, Spiros Bousbouras wrote:
>> [ Followup-To: comp.unix.programmer ]
>> On Sun, 13 Aug 2023 06:42:17 -0700 (PDT)
>> Malcolm McLean <malcolm.ar...@gmail.com> wrote:
>>> 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 .
>>
> That's unacceptable to me. My users will expect that when they see a program
> and type the name, it will either launch a GUI or print out. a brief message
> saying what the program is and what it does.
>>
>>> 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 "-"?

Yeah, obviously!

But on a program like gcc, you will also need -xc to tell it it's a C
file for example.

My own product is unconventional and uses -stdin. No filename is needed
then. Input is from the keyboard unless < has been used to redirect
input from a file, or file-like source.

I've never actually used it, and no other programs of mine have that.

But lots of programs will either take a file name, or enter interactive
mode such as the REPL of an interpreter if the file name is missing.

What is the behaviour you're after?

On Sunday, 13 August 2023 at 15:22:03 UTC+1, Bart wrote:
> On 13/08/2023 15:07, Malcolm McLean wrote:
> > On Sunday, 13 August 2023 at 14:55:57 UTC+1, Spiros Bousbouras wrote:
> >> [ Followup-To: comp.unix.programmer ]
> >> On Sun, 13 Aug 2023 06:42:17 -0700 (PDT)
> >> Malcolm McLean <malcolm.ar...@gmail.com> wrote:
> >>> 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 .
> >>
> > That's unacceptable to me. My users will expect that when they see a program
> > and type the name, it will either launch a GUI or print out. a brief message
> > saying what the program is and what it does.
> >>
> >>> 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 "-"?
> Yeah, obviously!
>
> But on a program like gcc, you will also need -xc to tell it it's a C
> file for example.
>
> My own product is unconventional and uses -stdin. No filename is needed
> then. Input is from the keyboard unless < has been used to redirect
> input from a file, or file-like source.
>
> I've never actually used it, and no other programs of mine have that.
>
> But lots of programs will either take a file name, or enter interactive
> mode such as the REPL of an interpreter if the file name is missing.
>
> What is the behaviour you're after?
>
I don't actually know.
The program is an XML to CSV file converter. My main motive for writing it
was to test the new vanilla XML parser. But some people like to set up
pipelines whereby the output of one program is chained to the input of another.
It's not. a style of working that I have ever used, however I understand that
in some environments, it's very important to have this ability.

I want it to support their needs.

On 13/08/2023 15:31, Malcolm McLean wrote:
> On Sunday, 13 August 2023 at 15:22:03 UTC+1, Bart wrote:
>> On 13/08/2023 15:07, Malcolm McLean wrote:
>>> On Sunday, 13 August 2023 at 14:55:57 UTC+1, Spiros Bousbouras wrote:
>>>> [ Followup-To: comp.unix.programmer ]
>>>> On Sun, 13 Aug 2023 06:42:17 -0700 (PDT)
>>>> Malcolm McLean <malcolm.ar...@gmail.com> wrote:
>>>>> 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 .
>>>>
>>> That's unacceptable to me. My users will expect that when they see a program
>>> and type the name, it will either launch a GUI or print out. a brief message
>>> saying what the program is and what it does.
>>>>
>>>>> 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 "-"?
>> Yeah, obviously!
>>
>> But on a program like gcc, you will also need -xc to tell it it's a C
>> file for example.
>>
>> My own product is unconventional and uses -stdin. No filename is needed
>> then. Input is from the keyboard unless < has been used to redirect
>> input from a file, or file-like source.
>>
>> I've never actually used it, and no other programs of mine have that.
>>
>> But lots of programs will either take a file name, or enter interactive
>> mode such as the REPL of an interpreter if the file name is missing.
>>
>> What is the behaviour you're after?
>>
> I don't actually know.
> The program is an XML to CSV file converter. My main motive for writing it
> was to test the new vanilla XML parser. But some people like to set up
> pipelines whereby the output of one program is chained to the input of another.
> It's not. a style of working that I have ever used, however I understand that
> in some environments, it's very important to have this ability.
>
> I want it to support their needs.

I think I would just have a differently named executable that did that:
take input from stdint and write output to stdout.

So no messing with options. It could even be the identical file (a copy
of the same EXE, or a link), but some code inside can look at name used
to invoke it.

Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>On Unix-lke systems, what is the convention for putting a program into a
>mode where it accepts input from stdin?

Every program 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

Or, it might be:

$ cat myinput.txt | myprogram (where the lack of argument presumes stdin)

or

$ cat myinput.txt | myprogram -

(where the single hyphen indicates that input is from stdin, vs. a filename
specified on the command line).

or

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

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.

Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>On Sunday, 13 August 2023 at 14:55:57 UTC+1, Spiros Bousbouras wrote:
>> [ Followup-To: comp.unix.programmer ]
>> On Sun, 13 Aug 2023 06:42:17 -0700 (PDT)
>> Malcolm McLean <malcolm.ar...@gmail.com> wrote:
>> > 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 .
>>
>That's unacceptable to me.

That's life.

Bart <bc@freeuk.com> writes:
>On 13/08/2023 15:07, Malcolm McLean wrote:
>> On Sunday, 13 August 2023 at 14:55:57 UTC+1, Spiros Bousbouras wrote:
>>> [ Followup-To: comp.unix.programmer ]
>>> On Sun, 13 Aug 2023 06:42:17 -0700 (PDT)
>>> Malcolm McLean <malcolm.ar...@gmail.com> wrote:
>>>> 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 .
>>>
>> That's unacceptable to me. My users will expect that when they see a program
>> and type the name, it will either launch a GUI or print out. a brief message
>> saying what the program is and what it does.
>>>
>>>> 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 "-"?
>
>Yeah, obviously!

Yes, obviously. He asked about unix. It has been quite clear
for several decades what the requirements are.

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

On Sun, 13 Aug 2023 07:07:55 -0700, Malcolm McLean wrote:

> On Sunday, 13 August 2023 at 14:55:57 UTC+1, Spiros Bousbouras wrote:
>> [ Followup-To: comp.unix.programmer ]
>> On Sun, 13 Aug 2023 06:42:17 -0700 (PDT)
>> Malcolm McLean <malcolm.ar...@gmail.com> wrote:
>> > On Unix-lke systems, what is the convention for putting a program into a
>> > mode where it accepts input from stdin?

The Unix convention is that a program /defaults/ to accepting data on stdin.
If the program can accept alternate input sources, then either
a) specific commandline arguments are used to change the input source, or
b) the input source is the last argument in the commandline argument list
(POSIX/SUS suggests that, if the last argument is '-', then the program
will revert back to accepting 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.

Yah, no. That behaviour is contrary to Unix convention. To get the help
summary, the Unix convention is to add a specific argument flag (typically -h),
to the commandline

>> > 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 .
>>
> That's unacceptable to me.

Then, it seems, that you are at odds with the Unix convention. Which is more
important to your users: consistency between the multitude of commandlines,
based on Unix conventions, or consistency between the few programs you source,
using conventions not "sanctioned" by Unix convention?

> My users will expect that when they see a program
> and type the name, it will either launch a GUI or print out. a brief message
> saying what the program is and what it does.
>>
>> > So do you pass an option
>> >
>> > myprogram -stdin
>> >
>> > or what is the normal way of solving this?

myprogram -

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

No. conventionally, the '-' stands in for "read from the existing stdin". The
'-' is not considered to be a filename (as in fopen("-","r") ).

--
Lew Pitcher
"In Skills We Trust"

On 2023-08-13, Lew Pitcher <lew.pitcher@digitalfreehold.ca> wrote:
> On Sun, 13 Aug 2023 07:07:55 -0700, Malcolm McLean wrote:
>
>> On Sunday, 13 August 2023 at 14:55:57 UTC+1, Spiros Bousbouras wrote:
>>> [ Followup-To: comp.unix.programmer ]
>>> On Sun, 13 Aug 2023 06:42:17 -0700 (PDT)
>>> Malcolm McLean <malcolm.ar...@gmail.com> wrote:
>>> > On Unix-lke systems, what is the convention for putting a program into a
>>> > mode where it accepts input from stdin?
>
> The Unix convention is that a program /defaults/ to accepting data on stdin.
> If the program can accept alternate input sources, then either
> a) specific commandline arguments are used to change the input source, or
> b) the input source is the last argument in the commandline argument list
> (POSIX/SUS suggests that, if the last argument is '-', then the program
> will revert back to accepting 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.
>
> Yah, no. That behaviour is contrary to Unix convention. To get the help
> summary, the Unix convention is to add a specific argument flag (typically -h),
> to the commandline
>
This is fine for a utility that requires arguments.

GNU Coreutils mv:

$ mv
mv: missing file operand
Try 'mv --help' for more information.

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

Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:

> On Sunday, 13 August 2023 at 14:55:57 UTC+1, Spiros Bousbouras wrote:
>> [ Followup-To: comp.unix.programmer ]
>> On Sun, 13 Aug 2023 06:42:17 -0700 (PDT)
>> Malcolm McLean <malcolm.ar...@gmail.com> wrote:
>> > 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 .
>>
> That's unacceptable to me. My users will expect that when they see a program
> and type the name, it will either launch a GUI or print out. a brief message
> saying what the program is and what it does.

(Context: an XML to CSV converter.)

Your Unix/Linux users probably expect something else. When I install
program xxx, my first action is "man xxx". Failing that, I try "xxx -h"
(or --help).

I have a few useful programs that clearly come from the world of Windows
and demand a file name either for input or for output. Fortunately,
Linux can deal with this situation because it offers /dev/stdin and
/dev/stout so pretty much any program can forced play nice in a
pipeline.

But to help things along, I'd suggest you (a) provide a -h (and/or
--help) flag that prints to stderr and then exits reading no input; (b)
interpret - as stdin (in an input position) and as stdout (where you
program expects an output file) as not everyone know about (or can
access) /dev/std{in,out}. I'd consider a -p (or --pipeline) flag that
turns off your default message and reads stdin and writes stdout.

--
Ben.

Kaz Kylheku <864-117-4973@kylheku.com> writes:
>On 2023-08-13, Lew Pitcher <lew.pitcher@digitalfreehold.ca> wrote:
>> On Sun, 13 Aug 2023 07:07:55 -0700, Malcolm McLean wrote:
>>
>>> On Sunday, 13 August 2023 at 14:55:57 UTC+1, Spiros Bousbouras wrote:
>>>> [ Followup-To: comp.unix.programmer ]
>>>> On Sun, 13 Aug 2023 06:42:17 -0700 (PDT)
>>>> Malcolm McLean <malcolm.ar...@gmail.com> wrote:
>>>> > On Unix-lke systems, what is the convention for putting a program into a
>>>> > mode where it accepts input from stdin?
>>
>> The Unix convention is that a program /defaults/ to accepting data on stdin.
>> If the program can accept alternate input sources, then either
>> a) specific commandline arguments are used to change the input source, or
>> b) the input source is the last argument in the commandline argument list
>> (POSIX/SUS suggests that, if the last argument is '-', then the program
>> will revert back to accepting 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.
>>
>> Yah, no. That behaviour is contrary to Unix convention. To get the help
>> summary, the Unix convention is to add a specific argument flag (typically -h),
>> to the commandline
>>
>
>This is fine for a utility that requires arguments.
>
>GNU Coreutils mv:
>
>$ mv
>mv: missing file operand
>Try 'mv --help' for more information.

The GNU utilities don't necessarily follow the POSIX guidelines, however.

Particularly with the verbose option naming (eg. --help instead of -h).

Any application that has more than 52 options should be split into
multiple applications or use a different configuration mechanism
(e.g. a configuration file).

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>
>> On Sunday, 13 August 2023 at 14:55:57 UTC+1, Spiros Bousbouras wrote:
>>> [ Followup-To: comp.unix.programmer ]
>>> On Sun, 13 Aug 2023 06:42:17 -0700 (PDT)
>>> Malcolm McLean <malcolm.ar...@gmail.com> wrote:
>>> > 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 .
>>>
>> That's unacceptable to me. My users will expect that when they see a program
>> and type the name, it will either launch a GUI or print out. a brief message
>> saying what the program is and what it does.
>
>(Context: an XML to CSV converter.)
>
>Your Unix/Linux users probably expect something else. When I install
>program xxx, my first action is "man xxx". Failing that, I try "xxx -h"
>(or --help).

Here's an example of a currently distributed xml command line
utility:

XMLLINT(1) xmllint Manual XMLLINT(1)

NAME
xmllint - command line XML tool

SYNOPSIS
xmllint [--version | --debug | --shell | --xpath "XPath_expression" |
--debugent | --copy | --recover | --noent | --noout | --nonet |
--path "PATH(S)" | --load-trace | --htmlout | --nowrap |
--valid | --postvalid | --dtdvalid URL | --dtdvalidfpi FPI |
--timing | --output FILE | --repeat | --insert | --compress |
--html | --xmlout | --push | --memory | --maxmem NBBYTES |
--nowarning | --noblanks | --nocdata | --format |
--encode ENCODING | --dropdtd | --nsclean | --testIO |
--catalogs | --nocatalogs | --auto | --xinclude |
--noxincludenode | --loaddtd | --dtdattr | --stream | --walker
| --pattern PATTERNVALUE | --chkregister | --relaxng SCHEMA |
--schema SCHEMA | --c14n] {XML-FILE(S)... | -}

xmllint --help

DESCRIPTION
The xmllint program parses one or more XML files, specified on the
command line as XML-FILE (or the standard input if the filename
provided is - ). It prints various types of output, depending upon the
options selected. It is useful for detecting errors both in XML code
and in the XML parser itself.

xmllint is included in libxml(3).

OPTIONS
xmllint accepts the following options (in alphabetical order):

....

scott@slp53.sl.home (Scott Lurndal) writes:
[...]
> Most programs in unix will accept '-?' or '-h' or some other flag
> to indicate that usage information is to be printed. Many utilities
> will print usage information if the input arguments are not valid.

Most Unix programs don't use '-?' because '?' is a shell wildcard
character. If you happen to have files in the current directory named
"-x" and "-y", "myprogram -?" expands to "myprogram -x -y".

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

In article <LtQSo3SOOU09AXJ1X@bongo-ra.co>,
Spiros Bousbouras <spibou@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.

--
I'll give him credit for one thing: He is (& will be) the most quotable President
ever. Books have been written about (GW) Bushisms, but Dubya's got nothing on Trump.

Tremendously wet - from the standpoint of water.

In article <87r0o6mqme.fsf@nosuchdomain.example.com>,
Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>scott@slp53.sl.home (Scott Lurndal) writes:
>[...]
>> Most programs in unix will accept '-?' or '-h' or some other flag
>> to indicate that usage information is to be printed. Many utilities
>> will print usage information if the input arguments are not valid.
>
>Most Unix programs don't use '-?' because '?' is a shell wildcard
>character. If you happen to have files in the current directory named
>"-x" and "-y", "myprogram -?" expands to "myprogram -x -y".

Indeed - and this is one of the many reasons why insisting on an option
(any option) to get help is a bad idea. Given that -? is kind of a
standard in the Windows world, many programs that get ported over to
Unix from Windows, will have this misfeature.

--
Modern Conservative: Someone who can take time out from demanding more
flag burning laws, more abortion laws, more drug laws, more obscenity
laws, and more police authority to make warrantless arrests to remind
us that we need to "get the government off our backs".

On 2023-08-14, Kenny McCormack <gazelle@shell.xmission.com> wrote:
> In article <LtQSo3SOOU09AXJ1X@bongo-ra.co>,
> Spiros Bousbouras <spibou@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 '-' ?"

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

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

In article <20230813200644.979@kylheku.com>,
Kaz Kylheku <864-117-4973@kylheku.com> wrote:
>On 2023-08-14, Kenny McCormack <gazelle@shell.xmission.com> wrote:
>> In article <LtQSo3SOOU09AXJ1X@bongo-ra.co>,
>> Spiros Bousbouras <spibou@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 '-' ?"
>
>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?

--

First of all, I do not appreciate your playing stupid here at all.

- Thomas 'PointedEars' Lahn -

Malcolm McLean <malcolm.arthur.mclean@gmail.com> wrote:
> 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.
> So do you pass an option
> myprogram -stdin
> or what is the normal way of solving this?

Some programs just default to...
FILE *fopen(), *input=stdin, *output=stdout;
requiring options...
myprogram -i inputfile -o outputfile
to override the defaults and fopen() the specified file(s).
Then you can alternatively...
myprogram -i inputfile -o outputfile
or use redirection for one or both...
myprogram < inputfile > outputfile
or just directly read/write from/to stdin/stdout.
--
John Forkosh ( mailto: j@f.com where j=john and f=forkosh )

On 2023-08-14, Kenny McCormack <gazelle@shell.xmission.com> wrote:
> In article <87r0o6mqme.fsf@nosuchdomain.example.com>,
> Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>>scott@slp53.sl.home (Scott Lurndal) writes:
>>[...]
>>> Most programs in unix will accept '-?' or '-h' or some other flag
>>> to indicate that usage information is to be printed. Many utilities
>>> will print usage information if the input arguments are not valid.
>>
>>Most Unix programs don't use '-?' because '?' is a shell wildcard
>>character. If you happen to have files in the current directory named
>>"-x" and "-y", "myprogram -?" expands to "myprogram -x -y".
>
> Indeed - and this is one of the many reasons why insisting on an option
> (any option) to get help is a bad idea. Given that -? is kind of a
> standard in the Windows world, many programs that get ported over to
> Unix from Windows, will have this misfeature.

Many command-line programs get ported to Unix from Windows?

Why don't they adjust their conventions?

/X /Y /Z /? is another convention; that one is smarter.

The system installation can arrange for the first three not
to be paths, and for /? not to match anything due to there
not being a one-character item in the root dir.

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

On 2023-08-14, Kenny McCormack wrote:

> In article <LtQSo3SOOU09AXJ1X@bongo-ra.co>,
> Spiros Bousbouras <spibou@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???

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?

--
Nuno Silva
(I'm not reading comp.lang.c, so it's possible I'm lacking some context)

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

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

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

Having a program misbehave because there happens to be a one-character
item in the root directory is a bad idea. (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.

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

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

help = opt_get(opt, "-help -h -H --help /H -?", 0);

On systems which expand wildcards in the shell, you have to type xmltocsv "-?"
to trigger help with the question mark option. But on Windows it should work
fine. Of course if you have an Xml file named "H" in the root directory then you
are in trouble. But you can pipe it to stdin and convert it that way.