Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #172150 > unrolled thread

Piping to stdin

Back to article view | Back to comp.lang.c

Contents

  Piping to stdin Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-13 06:42 -0700
    Re: Piping to stdin Spiros Bousbouras <spibou@gmail.com> - 2023-08-13 13:55 +0000
      Re: Piping to stdin Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-13 07:07 -0700
        Re: Piping to stdin Bart <bc@freeuk.com> - 2023-08-13 15:21 +0100
          Re: Piping to stdin Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-13 07:31 -0700
            Re: Piping to stdin Bart <bc@freeuk.com> - 2023-08-13 16:40 +0100
          Re: Piping to stdin scott@slp53.sl.home (Scott Lurndal) - 2023-08-13 16:08 +0000
        Re: Piping to stdin scott@slp53.sl.home (Scott Lurndal) - 2023-08-13 16:07 +0000
        Re: Piping to stdin Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2023-08-13 17:26 +0000
          Re: Piping to stdin Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-13 19:09 +0000
            Re: Piping to stdin scott@slp53.sl.home (Scott Lurndal) - 2023-08-13 20:45 +0000
        Re: Piping to stdin Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-08-13 20:53 +0100
          Re: Piping to stdin scott@slp53.sl.home (Scott Lurndal) - 2023-08-13 20:47 +0000
        Re: Piping to stdin gazelle@shell.xmission.com (Kenny McCormack) - 2023-08-14 00:59 +0000
          Re: Piping to stdin Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-14 03:07 +0000
            Re: Piping to stdin gazelle@shell.xmission.com (Kenny McCormack) - 2023-08-14 03:12 +0000
              Re: Piping to stdin kalevi@kolttonen.fi (Kalevi Kolttonen) - 2023-08-14 15:14 +0000
                Re: Piping to stdin "Gary R. Schmidt" <grschmidt@acm.org> - 2023-08-15 12:50 +1000
                  Re: Piping to stdin Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-15 04:59 +0000
                    Re: Piping to stdin Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-08-14 23:15 -0700
                    Re: Piping to stdin Richard Kettlewell <invalid@invalid.invalid> - 2023-08-15 08:50 +0100
                      Dealing with weird filenames (Was: Piping to stdin) gazelle@shell.xmission.com (Kenny McCormack) - 2023-08-15 08:10 +0000
                      Re: Piping to stdin David Brown <david.brown@hesbynett.no> - 2023-08-15 15:34 +0200
                        Re: Piping to stdin Richard Harnden <richard.nospam@gmail.com> - 2023-08-15 19:50 +0100
                          Re: Piping to stdin scott@slp53.sl.home (Scott Lurndal) - 2023-08-15 20:16 +0000
                          Re: Piping to stdin vallor <vallor@cultnix.org> - 2023-08-16 06:34 +0000
                        Re: Piping to stdin Richard Kettlewell <invalid@invalid.invalid> - 2023-08-16 17:39 +0100
                          Re: Piping to stdin scott@slp53.sl.home (Scott Lurndal) - 2023-08-16 17:37 +0000
                            Re: Piping to stdin gazelle@shell.xmission.com (Kenny McCormack) - 2023-08-16 17:43 +0000
                            Re: Piping to stdin Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-08-16 13:35 -0700
                            Re: Piping to stdin Phil Carmody <pc+usenet@asdf.org> - 2023-08-17 14:51 +0300
                      Re: Piping to stdin James Kuyper <jameskuyper@alumni.caltech.edu> - 2023-08-16 01:37 -0400
                        Re: Piping to stdin David Brown <david.brown@hesbynett.no> - 2023-08-16 13:14 +0200
                    Re: Piping to stdin Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2023-08-15 12:08 -0600
                      Re: Piping to stdin Richard Harnden <richard.nospam@gmail.com> - 2023-08-16 09:32 +0100
                        Re: Piping to stdin Phil Carmody <pc+usenet@asdf.org> - 2023-08-16 17:27 +0300
                  Re: Piping to stdin kalevi@kolttonen.fi (Kalevi Kolttonen) - 2023-08-15 14:30 +0000
                    Re: Piping to stdin Giovanni <lsodgf0@home.net.it> - 2023-08-15 17:14 +0200
                      Re: Piping to stdin gazelle@shell.xmission.com (Kenny McCormack) - 2023-08-15 15:48 +0000
                        Re: Piping to stdin kalevi@kolttonen.fi (Kalevi Kolttonen) - 2023-08-15 16:12 +0000
                          Re: Piping to stdin Muttley@dastardlyhq.com - 2023-08-15 16:15 +0000
                            Re: Piping to stdin kalevi@kolttonen.fi (Kalevi Kolttonen) - 2023-08-15 16:22 +0000
                              Re: Piping to stdin Muttley@dastardlyhq.com - 2023-08-17 10:26 +0000
                                Re: Piping to stdin kalevi@kolttonen.fi (Kalevi Kolttonen) - 2023-08-17 14:23 +0000
                                  Re: Piping to stdin scott@slp53.sl.home (Scott Lurndal) - 2023-08-17 15:25 +0000
                            Re: Piping to stdin Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-15 17:33 +0000
                            Re: Piping to stdin Phil Carmody <pc+usenet@asdf.org> - 2023-08-15 23:32 +0300
                              Re: Piping to stdin Muttley@dastardlyhq.com - 2023-08-17 10:32 +0000
                                Re: Piping to stdin Phil Carmody <pc+usenet@asdf.org> - 2023-08-17 14:57 +0300
                                  Re: Piping to stdin Michael S <already5chosen@yahoo.com> - 2023-08-17 05:14 -0700
                                  Wrecking a good thing? (Was: Piping to stdin) gazelle@shell.xmission.com (Kenny McCormack) - 2023-08-17 14:09 +0000
                                    Re: Wrecking a good thing? Phil Carmody <pc+usenet@asdf.org> - 2023-08-18 00:39 +0300
                                    Re: Wrecking a good thing? (Was: Piping to stdin) David Brown <david.brown@hesbynett.no> - 2023-08-18 11:17 +0200
                                  Re: Piping to stdin Muttley@dastardlyhq.com - 2023-08-17 15:14 +0000
                                  Re: Piping to stdin Öö Tiib <ootiib@hot.ee> - 2023-08-17 08:58 -0700
                                Re: Piping to stdin Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-17 13:52 +0000
                                  Re: Piping to stdin Muttley@dastardlyhq.com - 2023-08-17 15:20 +0000
                                  Re: Piping to stdin Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-08-17 13:43 -0700
                                  Re: Piping to stdin David Brown <david.brown@hesbynett.no> - 2023-08-18 11:28 +0200
                                Re: Piping to stdin Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-08-17 21:52 +0100
                                  Re: Piping to stdin Phil Carmody <pc+usenet@asdf.org> - 2023-08-19 13:33 +0300
                                    Re: Piping to stdin Oğuz <oguzismailuysal@gmail.com> - 2023-08-19 16:15 +0300
                                      Re: Piping to stdin Muttley@dastardlyhq.com - 2023-08-19 14:48 +0000
                                        Re: Piping to stdin scott@slp53.sl.home (Scott Lurndal) - 2023-08-20 17:24 +0000
                                          Re: Piping to stdin Muttley@dastardlyhq.com - 2023-08-20 19:21 +0000
                                        Re: Piping to stdin Rainer Weikusat <rweikusat@talktalk.net> - 2023-08-20 21:57 +0100
                                          What language is this? (Was: Piping to stdin) gazelle@shell.xmission.com (Kenny McCormack) - 2023-08-20 22:33 +0000
                                            Re: What language is this? (Was: Piping to stdin) scott@slp53.sl.home (Scott Lurndal) - 2023-08-21 01:26 +0000
                                              Re: What language is this? (Was: Piping to stdin) gazelle@shell.xmission.com (Kenny McCormack) - 2023-08-21 02:57 +0000
                                                Re: What language is this? Rainer Weikusat <rweikusat@talktalk.net> - 2023-08-21 17:16 +0100
                                                  Re: What language is this? gazelle@shell.xmission.com (Kenny McCormack) - 2023-08-21 19:10 +0000
                                                    Re: What language is this? Rainer Weikusat <rweikusat@talktalk.net> - 2023-08-21 20:31 +0100
                                                      Re: What language is this? gazelle@shell.xmission.com (Kenny McCormack) - 2023-08-21 20:29 +0000
                                                        Re: What language is this? Rainer Weikusat <rweikusat@talktalk.net> - 2023-08-21 21:48 +0100
                                              Re: What language is this? (Was: Piping to stdin) Muttley@dastardlyhq.com - 2023-08-21 06:50 +0000
                                    Re: Piping to stdin Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-08-19 21:14 +0100
                          Re: Piping to stdin Phil Carmody <pc+usenet@asdf.org> - 2023-08-15 23:24 +0300
                            Re: Piping to stdin Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2023-08-15 20:50 +0000
                              Re: Piping to stdin Phil Carmody <pc+usenet@asdf.org> - 2023-08-16 17:11 +0300
                                Re: Piping to stdin Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2023-08-16 15:25 +0000
                                  Re: Piping to stdin Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-16 19:29 +0000
                                  Re: Piping to stdin Phil Carmody <pc+usenet@asdf.org> - 2023-08-17 14:49 +0300
                          Re: Piping to stdin Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-08-16 03:20 +0100
                    Re: Piping to stdin Phil Carmody <pc+usenet@asdf.org> - 2023-08-15 18:33 +0300
          Re: Piping to stdin "Nuno Silva" <nunojsilva@invalid.invalid> - 2023-08-14 09:45 +0100
    Re: Piping to stdin scott@slp53.sl.home (Scott Lurndal) - 2023-08-13 16:06 +0000
      Re: Piping to stdin Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-08-13 17:09 -0700
        Re: Piping to stdin gazelle@shell.xmission.com (Kenny McCormack) - 2023-08-14 01:03 +0000
          Re: Piping to stdin Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-14 04:00 +0000
            Re: Piping to stdin Phil Carmody <pc+usenet@asdf.org> - 2023-08-14 12:20 +0300
            Re: Piping to stdin Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-08-14 02:44 -0700
              Re: Piping to stdin Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-14 03:54 -0700
                Re: Piping to stdin gazelle@shell.xmission.com (Kenny McCormack) - 2023-08-14 11:22 +0000
              Re: Piping to stdin Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-14 15:49 +0000
                Re: Piping to stdin Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-08-14 17:19 +0100
          Re: Piping to stdin Jim Jackson <jj@franjam.org.uk> - 2023-08-14 17:21 +0000
            Re: Piping to stdin Michael S <already5chosen@yahoo.com> - 2023-08-15 08:02 -0700
    Re: Piping to stdin John Forkosh <forkosh@panix.com> - 2023-08-14 03:15 +0000
    Re: Piping to stdin gazelle@shell.xmission.com (Kenny McCormack) - 2023-08-14 11:28 +0000
      Re: Piping to stdin scott@slp53.sl.home (Scott Lurndal) - 2023-08-14 15:41 +0000
        Re: Piping to stdin Richard Harnden <richard.nospam@gmail.com> - 2023-08-14 22:02 +0100
          Re: Piping to stdin scott@slp53.sl.home (Scott Lurndal) - 2023-08-14 21:14 +0000

Page 1 of 6  [1] 2 3 4 5 6  Next page →

#172150 — Piping to stdin

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?

[toc] | [next] | [standalone]

#172152

[ 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

[toc] | [prev] | [next] | [standalone]

#172153

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

[toc] | [prev] | [next] | [standalone]

#172154

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?

[toc] | [prev] | [next] | [standalone]

#172155

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.

[toc] | [prev] | [next] | [standalone]

#172157

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.

[toc] | [prev] | [next] | [standalone]

#172165

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

[toc] | [prev] | [next] | [standalone]

#172164

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.

[toc] | [prev] | [next] | [standalone]

#172169

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"

[toc] | [prev] | [next] | [standalone]

#172171

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

[toc] | [prev] | [next] | [standalone]

#172175

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

[toc] | [prev] | [next] | [standalone]

#172172

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.

[toc] | [prev] | [next] | [standalone]

#172178

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):

...

[toc] | [prev] | [next] | [standalone]

#172183

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.

[toc] | [prev] | [next] | [standalone]

#172188

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

[toc] | [prev] | [next] | [standalone]

#172189

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 -

[toc] | [prev] | [next] | [standalone]

#172225

In comp.unix.programmer Kenny McCormack <gazelle@shell.xmission.com> wrote:
> You know that - and I know that - but do they know that?

It makes no difference. In the real world nobody has
files named '-'.

br,
KK

[toc] | [prev] | [next] | [standalone]

#172239

On 15/08/2023 01:14, Kalevi Kolttonen wrote:
> In comp.unix.programmer Kenny McCormack <gazelle@shell.xmission.com> wrote:
>> You know that - and I know that - but do they know that?
> 
> It makes no difference. In the real world nobody has
> files named '-'.
> 
> br,
> KK

Ahah!  You don't have users, do you?

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

	Cheers,
		Gary	B-)

[toc] | [prev] | [next] | [standalone]

#172240

On 2023-08-15, Gary R. Schmidt <grschmidt@acm.org> wrote:
> On 15/08/2023 01:14, Kalevi Kolttonen wrote:
>> In comp.unix.programmer Kenny McCormack <gazelle@shell.xmission.com> wrote:
>>> You know that - and I know that - but do they know that?
>> 
>> It makes no difference. In the real world nobody has
>> files named '-'.
>> 
>> br,
>> KK
>
> Ahah!  You don't have users, do you?
>
> No doubt you also don't encounter filenames with spaces in them, or 
> carriage returns, or other garbage.

The interesction of:

- Users who make filenames like "-foo" and "monthly forecast.xls"

- Users who sit in a POSIX shell expanding wildcards like *
  in the same directory.

is probababy vanishingly nil, and the subset of those who do the
above in the same directory is even smaller.

Now admin scripts do have to handle the files created by the goofy users
in the first category.

Admin scripts don't ahve to worry about users creating a file
called -, because admin scripts won't be run in the directory
where the user did that. Not even scripts which do process
paths traversing that directory. The admin (or cron, or systemd or
whatever) will run those from somewhere else.

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

[toc] | [prev] | [next] | [standalone]

#172241

Kaz Kylheku <864-117-4973@kylheku.com> writes:
> On 2023-08-15, Gary R. Schmidt <grschmidt@acm.org> wrote:
>> On 15/08/2023 01:14, Kalevi Kolttonen wrote:
>>> In comp.unix.programmer Kenny McCormack <gazelle@shell.xmission.com> wrote:
>>>> You know that - and I know that - but do they know that?
>>> 
>>> It makes no difference. In the real world nobody has
>>> files named '-'.
>>> 
>>> br,
>>> KK
>>
>> Ahah!  You don't have users, do you?
>>
>> No doubt you also don't encounter filenames with spaces in them, or 
>> carriage returns, or other garbage.
>
> The interesction of:
>
> - Users who make filenames like "-foo" and "monthly forecast.xls"
>
> - Users who sit in a POSIX shell expanding wildcards like *
>   in the same directory.
>
> is probababy vanishingly nil, and the subset of those who do the
> above in the same directory is even smaller.

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

[...]

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

[toc] | [prev] | [next] | [standalone]

Page 1 of 6  [1] 2 3 4 5 6  Next page →

Back to top | Article view | comp.lang.c

csiph-web