Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #172150 > unrolled thread
| Started by | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| First post | 2023-08-13 06:42 -0700 |
| Last post | 2023-08-14 21:14 +0000 |
| Articles | 20 on this page of 102 — 27 participants |
Back to article view | Back to comp.lang.c
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 5 of 6 — ← Prev page 1 2 3 4 [5] 6 Next page →
| From | Kaz Kylheku <864-117-4973@kylheku.com> |
|---|---|
| Date | 2023-08-16 19:29 +0000 |
| Message-ID | <20230816121355.702@kylheku.com> |
| In reply to | #172383 |
On 2023-08-16, Lew Pitcher <lew.pitcher@digitalfreehold.ca> wrote: > On Wed, 16 Aug 2023 17:11:28 +0300, Phil Carmody wrote: > >> Lew Pitcher <lew.pitcher@digitalfreehold.ca> writes: >>> On Tue, 15 Aug 2023 23:24:28 +0300, Phil Carmody wrote: > [snip] >>>>> I guess the stdin convention '-' is decades old. >>>>> It was chosen because they had pick something that >>>>> is short and not likely to exist as a real file. >>>> >>>> I propose that '|' might have been better - it's even mnemonic. >>> >>> But, '|' conflicts with the shell pipe character, and would need >>> a workaround in some cases. For example, >> >> It's doing something special, why wouldn't you expect to do something >> special to make use of it? > > Okay, then. How about a counter proposal: > For Unix shells, the < character indicates redirection of stdin. > I propose that '<' might have been a better choice as a standard > program option to flag "read from stdin" than either '|' /or/ '-' > were. :-) Counter-counter proposal #1: The issue is that "commmand *" can generate the - name or arguments that look like options. But * skips things that begin with dot! So, use that for options: rm .rf * Counter-couner proposal #2: Problem is that we often operate on dot files. Solution: have it so that * skips names that start with dash; so if someone wants * to match - or -rf, they must use "command -*". Bash could have a "shopt -s dashglob" to make * match dashed items. I think it might be worth implementing dashglob Bash, enabled by default. -- TXR Programming Language: http://nongnu.org/txr Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal Mastodon: @Kazinator@mstdn.ca
[toc] | [prev] | [next] | [standalone]
| From | Phil Carmody <pc+usenet@asdf.org> |
|---|---|
| Date | 2023-08-17 14:49 +0300 |
| Message-ID | <87350h28j9.fsf@fatphil.org> |
| In reply to | #172383 |
Lew Pitcher <lew.pitcher@digitalfreehold.ca> writes: > On Wed, 16 Aug 2023 17:11:28 +0300, Phil Carmody wrote: >> Lew Pitcher <lew.pitcher@digitalfreehold.ca> writes: >>> On Tue, 15 Aug 2023 23:24:28 +0300, Phil Carmody wrote: > [snip] >>>>> I guess the stdin convention '-' is decades old. >>>>> It was chosen because they had pick something that >>>>> is short and not likely to exist as a real file. >>>> >>>> I propose that '|' might have been better - it's even mnemonic. >>> >>> But, '|' conflicts with the shell pipe character, and would need >>> a workaround in some cases. For example, >> >> It's doing something special, why wouldn't you expect to do something >> special to make use of it? > > Okay, then. How about a counter proposal: > For Unix shells, the < character indicates redirection of stdin. > I propose that '<' might have been a better choice as a standard > program option to flag "read from stdin" than either '|' /or/ '-' > were. :-) Why *better* than '|', rather than *equally good as*, given that the logic is absolutely equivalent? 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/
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2023-08-16 03:20 +0100 |
| Message-ID | <87msyrhgnq.fsf@bsb.me.uk> |
| In reply to | #172311 |
kalevi@kolttonen.fi (Kalevi Kolttonen) writes: > I guess the stdin convention '-' is decades old. > It was chosen because they had pick something that > is short and not likely to exist as a real file. If I were doing this all from scratch, I'd consider choosing /- as the convention. It's never a "user" file, and anyone capable of creating it should know how to remove it. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Phil Carmody <pc+usenet@asdf.org> |
|---|---|
| Date | 2023-08-15 18:33 +0300 |
| Message-ID | <87bkf848xw.fsf@fatphil.org> |
| In reply to | #172283 |
kalevi@kolttonen.fi (Kalevi Kolttonen) writes: > The "problem" of having '-' as a filename is > a complete non-issue that only has theoretical > interest. On Unix, no matter which stdin > convention you choose, you run the risk of > someone having that convention as a filename. Not everything is a valid filename in unix. If you can exclude the possibility of accepting a directory, then you could have adopted something that could only be a directory as the placeholder, such as '.', or '/', or '-/', or .... Ooof, technically you could use '', as that's a forbidden filename too, but I'm not suggesting that. > On Unix, it used to be the case that only > NUL-characters and '/' were out of question. I > suppose some filesystems place more restrictions > on filenames nowadays. There are many contexts where certain characters have special meanings, and so it makes sense to avoid them in filenames (colons spring to mind, but of course some shell characters). However, sense has never been a proven property of the modern computer user. At least the order of command processing is mostly sane, so that you can't use malicious filenames to inject shell metacharacters into commandlines, it's only the programs being executed that could get confused by what they receive. Phil -- We are no longer hunters and nomads. No longer awed and frightened, as we have gained some understanding of the world in which we live. As such, we can cast aside childish remnants from the dawn of our civilization. -- NotSanguine on SoylentNews, after Eugen Weber in /The Western Tradition/
[toc] | [prev] | [next] | [standalone]
| From | "Nuno Silva" <nunojsilva@invalid.invalid> |
|---|---|
| Date | 2023-08-14 09:45 +0100 |
| Message-ID | <ubcpj3$28035$1@dont-email.me> |
| In reply to | #172183 |
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)
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2023-08-13 16:06 +0000 |
| Message-ID | <mc7CM.741128$GMN3.387092@fx16.iad> |
| In reply to | #172150 |
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.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2023-08-13 17:09 -0700 |
| Message-ID | <87r0o6mqme.fsf@nosuchdomain.example.com> |
| In reply to | #172163 |
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 */
[toc] | [prev] | [next] | [standalone]
| From | gazelle@shell.xmission.com (Kenny McCormack) |
|---|---|
| Date | 2023-08-14 01:03 +0000 |
| Message-ID | <ubbugh$3hium$2@news.xmission.com> |
| In reply to | #172180 |
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".
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <864-117-4973@kylheku.com> |
|---|---|
| Date | 2023-08-14 04:00 +0000 |
| Message-ID | <20230813201038.114@kylheku.com> |
| In reply to | #172184 |
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
[toc] | [prev] | [next] | [standalone]
| From | Phil Carmody <pc+usenet@asdf.org> |
|---|---|
| Date | 2023-08-14 12:20 +0300 |
| Message-ID | <87o7ja3rpp.fsf@fatphil.org> |
| In reply to | #172192 |
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/
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2023-08-14 02:44 -0700 |
| Message-ID | <87il9ilzzq.fsf@nosuchdomain.example.com> |
| In reply to | #172192 |
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 */
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2023-08-14 03:54 -0700 |
| Message-ID | <758f0a4b-d8c9-44db-af3e-2c8ac1ff2354n@googlegroups.com> |
| In reply to | #172202 |
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.
[toc] | [prev] | [next] | [standalone]
| From | gazelle@shell.xmission.com (Kenny McCormack) |
|---|---|
| Date | 2023-08-14 11:22 +0000 |
| Message-ID | <ubd2q4$3i4qq$1@news.xmission.com> |
| In reply to | #172210 |
In article <758f0a4b-d8c9-44db-af3e-2c8ac1ff2354n@googlegroups.com>, Malcolm McLean <malcolm.arthur.mclean@gmail.com> wrote: ... >I've just coded in this line. > > help = opt_get(opt, "-help -h -H --help /H -?", 0); > >On systems which expand wildcards in the shell, you have to type >xmltocsv "-?" to trigger help with the question mark option. But on >Windows it should work fine. Of course if you have an Xml file named >"H" in the root directory then you are in trouble. But you can pipe it >to stdin and convert it that way. I don't know if you're read/parsed my earlier responses on this thread (yet), but I still think it is perfectly reasonable to display the help message when the program is run with no args and stdin is a terminal (as checked with isatty()). You can then also display it on any other arg error; this eliminates any need to check explicitly for -h/-H/-?/--help/etc, etc. isatty() works on Unix/Linux/MacOS, but I suppose may not work in (native) Windows. I don't know if it works in Cygwin/WSL/etc (It probably does; I've just never checked it). Alternatively, you could dispense with isatty() and require a - as a (pseudo-) filename to read stdin. -- The last time a Republican cared about you, you were a fetus.
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <864-117-4973@kylheku.com> |
|---|---|
| Date | 2023-08-14 15:49 +0000 |
| Message-ID | <20230814084006.350@kylheku.com> |
| In reply to | #172202 |
On 2023-08-14, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote: > Kaz Kylheku <864-117-4973@kylheku.com> writes: >> On 2023-08-14, Kenny McCormack <gazelle@shell.xmission.com> wrote: >>> In article <87r0o6mqme.fsf@nosuchdomain.example.com>, >>> Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote: >>>>scott@slp53.sl.home (Scott Lurndal) writes: >>>>[...] >>>>> Most programs in unix will accept '-?' or '-h' or some other flag >>>>> to indicate that usage information is to be printed. Many utilities >>>>> will print usage information if the input arguments are not valid. >>>> >>>>Most Unix programs don't use '-?' because '?' is a shell wildcard >>>>character. If you happen to have files in the current directory named >>>>"-x" and "-y", "myprogram -?" expands to "myprogram -x -y". >>> >>> Indeed - and this is one of the many reasons why insisting on an option >>> (any option) to get help is a bad idea. Given that -? is kind of a >>> standard in the Windows world, many programs that get ported over to >>> Unix from Windows, will have this misfeature. >> >> Many command-line programs get ported to Unix from Windows? >> >> Why don't they adjust their conventions? >> >> /X /Y /Z /? is another convention; that one is smarter. >> >> The system installation can arrange for the first three not >> to be paths, and for /? not to match anything due to there >> not being a one-character item in the root dir. > > Having a program misbehave because there happens to be a one-character > item in the root directory is a bad idea. But the problem of wildcard expansion producing that by accident seems very improbable. The * pattern won't expand to anything that has a leading slash. You would have to explicitly do utility /* where /* expands to a set of paths the first of which (and possibly others) look like an option. I don't think that's super common compared to *. This seems like less of a threat than utility * expanding to arguments that look like - options. I would also disallow clumping options like /abc instead of /a /b /c, so the clashing namespace is just one character.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2023-08-14 17:19 +0100 |
| Message-ID | <87sf8lha03.fsf@bsb.me.uk> |
| In reply to | #172229 |
Kaz Kylheku <864-117-4973@kylheku.com> writes: > On 2023-08-14, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote: >> Kaz Kylheku <864-117-4973@kylheku.com> writes: >>> On 2023-08-14, Kenny McCormack <gazelle@shell.xmission.com> wrote: >>>> In article <87r0o6mqme.fsf@nosuchdomain.example.com>, >>>> Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote: >>>>>scott@slp53.sl.home (Scott Lurndal) writes: >>>>>[...] >>>>>> Most programs in unix will accept '-?' or '-h' or some other flag >>>>>> to indicate that usage information is to be printed. Many utilities >>>>>> will print usage information if the input arguments are not valid. >>>>> >>>>>Most Unix programs don't use '-?' because '?' is a shell wildcard >>>>>character. If you happen to have files in the current directory named >>>>>"-x" and "-y", "myprogram -?" expands to "myprogram -x -y". >>>> >>>> Indeed - and this is one of the many reasons why insisting on an option >>>> (any option) to get help is a bad idea. Given that -? is kind of a >>>> standard in the Windows world, many programs that get ported over to >>>> Unix from Windows, will have this misfeature. >>> >>> Many command-line programs get ported to Unix from Windows? >>> >>> Why don't they adjust their conventions? >>> >>> /X /Y /Z /? is another convention; that one is smarter. >>> >>> The system installation can arrange for the first three not >>> to be paths, and for /? not to match anything due to there >>> not being a one-character item in the root dir. >> >> Having a program misbehave because there happens to be a one-character >> item in the root directory is a bad idea. > > But the problem of wildcard expansion producing that by accident > seems very improbable. > > The * pattern won't expand to anything that has a leading slash. You > would have to explicitly do > > utility /* > > where /* expands to a set of paths the first of which (and possibly > others) look like an option. But you are suggesting users type /? for help. That could match a file and produce almost any other flag as a result. I suspect that was Keith's main concern. > I would also disallow clumping options like /abc instead > of /a /b /c, so the clashing namespace is just one character. You could (as world king) disallow combining flags with the '-' convention as well. You /have/ to with the '/' convention which makes it /less/ smart in my book. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Jim Jackson <jj@franjam.org.uk> |
|---|---|
| Date | 2023-08-14 17:21 +0000 |
| Message-ID | <slrnudkokv.7u3.jj@iridium.wf32df> |
| In reply to | #172184 |
> .... 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?
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2023-08-15 08:02 -0700 |
| Message-ID | <2ead585d-4d20-4d78-9183-f0ccf5055bedn@googlegroups.com> |
| In reply to | #172234 |
On Monday, August 14, 2023 at 8:21:49 PM UTC+3, Jim Jackson wrote: > > .... Given that -? is kind of a > > standard in the Windows world, many programs that get ported over to > > Unix from Windows, will have this misfeature. > > > Command line programs ported from Windows to Unix !!!!! Sounds like an > oxymoron to me :-) > > Do you have some in mind? Probably many thousands of programs every year. Almost exclusively in-house stuff so you will never see them. I ported one less than a year ago. Would have ported another one if had time and wasn't lazy.
[toc] | [prev] | [next] | [standalone]
| From | John Forkosh <forkosh@panix.com> |
|---|---|
| Date | 2023-08-14 03:15 +0000 |
| Message-ID | <ubc689$82p$1@reader2.panix.com> |
| In reply to | #172150 |
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 )
[toc] | [prev] | [next] | [standalone]
| From | gazelle@shell.xmission.com (Kenny McCormack) |
|---|---|
| Date | 2023-08-14 11:28 +0000 |
| Message-ID | <ubd359$3i4qq$2@news.xmission.com> |
| In reply to | #172150 |
In article <874jl1j4rh.fsf@bsb.me.uk>, Ben Bacarisse <ben.usenet@bsb.me.uk> wrote: ... >Agreed. And newer programs will follow the ancient convention. The >distinction, it seems to me, is not age but purpose. If you can easily >see a program being used in a pipeline, it should silently read stdin, No. As I mentioned earlier, if "cat" (et al) was being designed today, it wouldn't work like that. Remember that, in the early days of Unix, typing commands on a 110 baud teletype, keeping typing to an absolute minimum was a top priority. Today, not so much. -- The randomly chosen signature file that would have appeared here is more than 4 lines long. As such, it violates one or more Usenet RFCs. In order to remain in compliance with said RFCs, the actual sig can be found at the following URL: http://user.xmission.com/~gazelle/Sigs/FreeCollege
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2023-08-14 15:41 +0000 |
| Message-ID | <sWrCM.59049$m8Ke.15249@fx08.iad> |
| In reply to | #172212 |
gazelle@shell.xmission.com (Kenny McCormack) writes: >In article <874jl1j4rh.fsf@bsb.me.uk>, >Ben Bacarisse <ben.usenet@bsb.me.uk> wrote: >... >>Agreed. And newer programs will follow the ancient convention. The >>distinction, it seems to me, is not age but purpose. If you can easily >>see a program being used in a pipeline, it should silently read stdin, > >No. As I mentioned earlier, if "cat" (et al) was being designed today, it >wouldn't work like that. Why do you believe that?
[toc] | [prev] | [next] | [standalone]
Page 5 of 6 — ← Prev page 1 2 3 4 [5] 6 Next page →
Back to top | Article view | comp.lang.c
csiph-web