Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Re: Piping to stdin
45 views
Skip to first unread message
Spiros Bousbouras
Aug 13, 2023, 9:55:48 AM8/13/23
to
[ 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 .
> 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 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 .
> 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
Spiros Bousbouras
Aug 13, 2023, 10:27:40 AM8/13/23
to
On Sun, 13 Aug 2023 07:07:55 -0700 (PDT)
Malcolm McLean <malcolm.ar...@gmail.com> wrote:
Yes.
Malcolm McLean <malcolm.ar...@gmail.com> 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.
[...]
> > [ 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.
> > > 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 "-"?
> > >
> > > myprogram -stdin
> > >
> > > or what is the normal way of solving this?
> > - (a single dash) as argument. Even if the programme accepts multiple file
> > name arguments , a single dash among those means "read from stdin".
> >
Yes.
Kenny McCormack
Aug 13, 2023, 8:59:54 PM8/13/23
to
In article <LtQSo3SO...@bongo-ra.co>,
Spiros Bousbouras <spi...@gmail.com> wrote:
...
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.
Spiros Bousbouras <spi...@gmail.com> wrote:
...
>> So conventionally the file name is "-"?
>
>Yes.
Yes, but, as indicated, it is just that - a convention. The program has to
>
>Yes.
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.
Kenny McCormack
Aug 13, 2023, 9:03:18 PM8/13/23
to
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.
--
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".
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.
--
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".
Kaz Kylheku
Aug 13, 2023, 11:07:55 PM8/13/23
to
On 2023-08-14, Kenny McCormack <gaz...@shell.xmission.com> wrote:
> In article <LtQSo3SO...@bongo-ra.co>,
> Spiros Bousbouras <spi...@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 "-",
> In article <LtQSo3SO...@bongo-ra.co>,
> Spiros Bousbouras <spi...@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 '-' ?"
such as "./-".
--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazi...@mstdn.ca
Kenny McCormack
Aug 13, 2023, 11:12:48 PM8/13/23
to
In article <202308132...@kylheku.com>,
--
First of all, I do not appreciate your playing stupid here at all.
- Thomas 'PointedEars' Lahn -
Kaz Kylheku <864-11...@kylheku.com> wrote:
>On 2023-08-14, Kenny McCormack <gaz...@shell.xmission.com> wrote:
>> In article <LtQSo3SO...@bongo-ra.co>,
>> Spiros Bousbouras <spi...@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?
>On 2023-08-14, Kenny McCormack <gaz...@shell.xmission.com> wrote:
>> In article <LtQSo3SO...@bongo-ra.co>,
>> Spiros Bousbouras <spi...@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 "./-".
--
First of all, I do not appreciate your playing stupid here at all.
- Thomas 'PointedEars' Lahn -
Joe Pfeiffer
Aug 13, 2023, 11:27:04 PM8/13/23
to
Spiros Bousbouras <spi...@gmail.com> writes:
> [ 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 .
No, the typical user will expect help text from just typing the command
> [ 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 .
name (notwithstanding ancient programs like cat). I typically treat no
args the same as -h
>> 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".
Kaz Kylheku
Aug 14, 2023, 12:00:53 AM8/14/23
to
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?
> 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.
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.
Nuno Silva
Aug 14, 2023, 4:45:28 AM8/14/23
to
On 2023-08-14, Kenny McCormack wrote:
> In article <LtQSo3SO...@bongo-ra.co>,
> Spiros Bousbouras <spi...@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
> In article <LtQSo3SO...@bongo-ra.co>,
> Spiros Bousbouras <spi...@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???
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)
Spiros Bousbouras
Aug 14, 2023, 5:24:15 AM8/14/23
to
On Sun, 13 Aug 2023 21:26:59 -0600
Joe Pfeiffer <pfei...@cs.nmsu.edu> wrote:
> Spiros Bousbouras <spi...@gmail.com> writes:
>
> > [ 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 .
>
> No, the typical user will expect help text from just typing the command
> name (notwithstanding ancient programs like cat). I typically treat no
> args the same as -h
Not to mention grep , awk , sed , sort , bc , od , etc. Being "ancient"
Joe Pfeiffer <pfei...@cs.nmsu.edu> wrote:
> Spiros Bousbouras <spi...@gmail.com> writes:
>
> > [ 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 .
>
> No, the typical user will expect help text from just typing the command
> name (notwithstanding ancient programs like cat). I typically treat no
> args the same as -h
means that their conventions are more firmly established so why would a
user expect something else ?
Phil Carmody
Aug 14, 2023, 5:36:50 AM8/14/23
to
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.
So if I want to grep case-insensitively for whole words, and have line
> 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.
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/
Keith Thompson
Aug 14, 2023, 5:44:50 AM8/14/23
to
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
> 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.
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.T...@gmail.com
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */
Ben Bacarisse
Aug 14, 2023, 6:30:01 AM8/14/23
to
distinction, it seems to me, is not age but purpose. If you can easily
see a program being used in a pipeline, it should silently read stdin,
but if that usage is rare, it should interpret '-' as a convention for
reading stdin.
For example, gcc on it's own complains, but
echo "int f() { return 1; }" | gcc -S -xc - -o -
works as expected.
--
Ben.
Kenny McCormack
Aug 14, 2023, 7:28:46 AM8/14/23
to
In article <874jl1j...@bsb.me.uk>,
Ben Bacarisse <ben.u...@bsb.me.uk> wrote:
...
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
Ben Bacarisse <ben.u...@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
>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,
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
Kalevi Kolttonen
Aug 14, 2023, 11:14:43 AM8/14/23
to
In comp.unix.programmer Kenny McCormack <gaz...@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
> You know that - and I know that - but do they know that?
files named '-'.
br,
KK
Scott Lurndal
Aug 14, 2023, 11:41:17 AM8/14/23
to
gaz...@shell.xmission.com (Kenny McCormack) writes:
>In article <874jl1j...@bsb.me.uk>,
>Ben Bacarisse <ben.u...@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?
>In article <874jl1j...@bsb.me.uk>,
>Ben Bacarisse <ben.u...@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.
Kaz Kylheku
Aug 14, 2023, 11:49:25 AM8/14/23
to
seems very improbable.
The * pattern won't expand to anything that has a leading slash. You
would have to explicitly do
utility /*
where /* expands to a set of paths the first of which (and possibly
others) look like an option. I don't think that's super common
compared to *.
This seems like less of a threat than
utility *
expanding to arguments that look like - options.
I would also disallow clumping options like /abc instead
of /a /b /c, so the clashing namespace is just one character.
Ben Bacarisse
Aug 14, 2023, 12:19:52 PM8/14/23
to
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.
convention as well. You /have/ to with the '/' convention which makes
it /less/ smart in my book.
--
Ben.
Jim Jackson
Aug 14, 2023, 1:21:40 PM8/14/23
to
> .... Given that -? is kind of a
oxymoron to me :-)
Do you have some in mind?
> 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
> Unix from Windows, will have this misfeature.
>
oxymoron to me :-)
Do you have some in mind?
Richard Harnden
Aug 14, 2023, 5:02:16 PM8/14/23
to
What's not to love?
Scott Lurndal
Aug 14, 2023, 5:14:26 PM8/14/23
to
Gary R. Schmidt
Aug 14, 2023, 10:54:11 PM8/14/23
to
No doubt you also don't encounter filenames with spaces in them, or
carriage returns, or other garbage.
Cheers,
Gary B-)
Kaz Kylheku
Aug 15, 2023, 12:59:17 AM8/15/23
to
- Users who make filenames like "-foo" and "monthly forecast.xls"
- Users who sit in a POSIX shell expanding wildcards like *
in the same directory.
is probababy vanishingly nil, and the subset of those who do the
above in the same directory is even smaller.
Now admin scripts do have to handle the files created by the goofy users
in the first category.
Admin scripts don't ahve to worry about users creating a file
called -, because admin scripts won't be run in the directory
where the user did that. Not even scripts which do process
paths traversing that directory. The admin (or cron, or systemd or
whatever) will run those from somewhere else.
Keith Thompson
Aug 15, 2023, 2:16:04 AM8/15/23
to
Kaz Kylheku <864-11...@kylheku.com> writes:
> On 2023-08-15, Gary R. Schmidt <grsc...@acm.org> wrote:
>> On 15/08/2023 01:14, Kalevi Kolttonen wrote:
>>> In comp.unix.programmer Kenny McCormack <gaz...@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
> On 2023-08-15, Gary R. Schmidt <grsc...@acm.org> wrote:
>> On 15/08/2023 01:14, Kalevi Kolttonen wrote:
>>> In comp.unix.programmer Kenny McCormack <gaz...@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.
names, and who often find it convenient to `cd` to a directory
containing such files.
[...]
Richard Kettlewell
Aug 15, 2023, 3:50:53 AM8/15/23
to
Kaz Kylheku <864-11...@kylheku.com> writes:
> On 2023-08-15, Gary R. Schmidt <grsc...@acm.org> wrote:
>> Ahah! You don't have users, do you?
>>
>> No doubt you also don't encounter filenames with spaces in them, or
>> carriage returns, or other garbage.
>
> The interesction of:
>
> - Users who make filenames like "-foo" and "monthly forecast.xls"
>
> - Users who sit in a POSIX shell expanding wildcards like *
> in the same directory.
>
> is probababy vanishingly nil, and the subset of those who do the
> above in the same directory is even smaller.
The cases I’ve encountered are where someone accidentally creates a file
> On 2023-08-15, Gary R. Schmidt <grsc...@acm.org> wrote:
>> Ahah! You don't have users, do you?
>>
>> No doubt you also don't encounter filenames with spaces in them, or
>> carriage returns, or other garbage.
>
> The interesction of:
>
> - Users who make filenames like "-foo" and "monthly forecast.xls"
>
> - Users who sit in a POSIX shell expanding wildcards like *
> in the same directory.
>
> is probababy vanishingly nil, and the subset of those who do the
> above in the same directory is even smaller.
with a weird name (starts with - or whatever) and then has trouble
deleting it. I don’t think they got as far as having accidents with
wildcards in the cases I remember, but the basic setup of a file with a
ridiculous name and a non-expert user does happen occasionally.
> Now admin scripts do have to handle the files created by the goofy
> users in the first category.
>
> Admin scripts don't ahve to worry about users creating a file called
> -, because admin scripts won't be run in the directory where the user
> did that. Not even scripts which do process paths traversing that
> directory. The admin (or cron, or systemd or whatever) will run those
> from somewhere else.
user-created file is a /tmp cleaner. Not quite the same issue as we
started with here but depending on how experienced the script author is
there is plenty of room for accidental or adversarial mischief.
--
https://www.greenend.org.uk/rjk/
Kenny McCormack
Aug 15, 2023, 4:10:52 AM8/15/23
to
In article <wwvleec...@LkoBDZeT.terraraq.uk>,
Richard Kettlewell <inv...@invalid.invalid> wrote:
...
equivalent - whatever they are calling it in Unix/Linux these days).
Weirdly named files are no problem to delete from a GUI, since no shell is
involved.
--
If Jeb is Charlie Brown kicking a football-pulled-away, Mitt is a '50s
housewife with a black eye who insists to her friends the roast wasn't
dry.
Richard Kettlewell <inv...@invalid.invalid> wrote:
...
>The cases I've encountered are where someone accidentally creates a file
>with a weird name (starts with - or whatever) and then has trouble
>deleting it. I don't think they got as far as having accidents with
>wildcards in the cases I remember, but the basic setup of a file with a
>ridiculous name and a non-expert user does happen occasionally.
This is a situation where using a GUI file manager (Windows Explorer
>with a weird name (starts with - or whatever) and then has trouble
>deleting it. I don't think they got as far as having accidents with
>wildcards in the cases I remember, but the basic setup of a file with a
>ridiculous name and a non-expert user does happen occasionally.
equivalent - whatever they are calling it in Unix/Linux these days).
Weirdly named files are no problem to delete from a GUI, since no shell is
involved.
--
If Jeb is Charlie Brown kicking a football-pulled-away, Mitt is a '50s
housewife with a black eye who insists to her friends the roast wasn't
dry.
David Brown
Aug 15, 2023, 9:34:06 AM8/15/23
to
On 15/08/2023 09:50, Richard Kettlewell wrote:
> Kaz Kylheku <864-11...@kylheku.com> writes:
>> On 2023-08-15, Gary R. Schmidt <grsc...@acm.org> wrote:
>>> Ahah! You don't have users, do you?
>>>
>>> No doubt you also don't encounter filenames with spaces in them, or
>>> carriage returns, or other garbage.
>>
>> The interesction of:
>>
>> - Users who make filenames like "-foo" and "monthly forecast.xls"
>>
>> - Users who sit in a POSIX shell expanding wildcards like *
>> in the same directory.
>>
>> is probababy vanishingly nil, and the subset of those who do the
>> above in the same directory is even smaller.
>
> The cases I’ve encountered are where someone accidentally creates a file
> with a weird name (starts with - or whatever) and then has trouble
> deleting it. I don’t think they got as far as having accidents with
> wildcards in the cases I remember, but the basic setup of a file with a
> ridiculous name and a non-expert user does happen occasionally.
>
It's usually sufficient just to put the awkward name inside quotation marks.
> Kaz Kylheku <864-11...@kylheku.com> writes:
>> On 2023-08-15, Gary R. Schmidt <grsc...@acm.org> wrote:
>>> Ahah! You don't have users, do you?
>>>
>>> No doubt you also don't encounter filenames with spaces in them, or
>>> carriage returns, or other garbage.
>>
>> The interesction of:
>>
>> - Users who make filenames like "-foo" and "monthly forecast.xls"
>>
>> - Users who sit in a POSIX shell expanding wildcards like *
>> in the same directory.
>>
>> is probababy vanishingly nil, and the subset of those who do the
>> above in the same directory is even smaller.
>
> The cases I’ve encountered are where someone accidentally creates a file
> with a weird name (starts with - or whatever) and then has trouble
> deleting it. I don’t think they got as far as having accidents with
> wildcards in the cases I remember, but the basic setup of a file with a
> ridiculous name and a non-expert user does happen occasionally.
>
Kalevi Kolttonen
Aug 15, 2023, 10:30:18 AM8/15/23
to
In comp.unix.programmer Gary R. Schmidt <grsc...@acm.org> wrote:
> On 15/08/2023 01:14, Kalevi Kolttonen wrote:
> Ahah! You don't have users, do you?
No, I no longer have users. However, I used to have
> On 15/08/2023 01:14, Kalevi Kolttonen wrote:
> Ahah! You don't have users, do you?
50 000 - 60 000 users, but only a tiny minority
of them had Unix shell access. The vast majority
was email users.
I certainly never ever encountered anyone
with filename or email folder name being '-'.
> No doubt you also don't encounter filenames with
> spaces in them, or carriage returns, or other
> garbage.
as filenams with spaces are very common indeed.
The "problem" of having '-' as a filename is
a complete non-issue that only has theoretical
interest. On Unix, no matter which stdin
convention you choose, you run the risk of
someone having that convention as a filename.
On Unix, it used to be the case that only
NUL-characters and '/' were out of question. I
suppose some filesystems place more restrictions
on filenames nowadays.
br,
KK
Giovanni
Aug 15, 2023, 11:14:05 AM8/15/23
to
On 8/15/23 16:30, Kalevi Kolttonen wrote:
> On Unix, it used to be the case that only
> NUL-characters and '/' were out of question. I
> suppose some filesystems place more restrictions
> on filenames nowadays.
There are still no restriction on file names. It`s only a problem of the
> 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.
program. If it expects a file name as input, it has to test if the
argument passed is - in which case it reads from stdin. And, usually,
this works even if the file system has in the current directory a file
named -
To use the file - you should pass it to the program as ./-
Ciao
Giovanni
--
A computer is like an air conditioner,
it stops working when you open Windows.
< https://giovanni.homelinux.net/ >
Kenny McCormack
Aug 15, 2023, 11:48:28 AM8/15/23
to
In article <ubg4no$8kb$1...@milena.home.net.it>,
And I know that.
And even Kalevi knows that.
But do they know that???
--
The randomly chosen signature file that would have appeared here is more than 4
lines long. As such, it violates one or more Usenet RFCs. In order to remain
in compliance with said RFCs, the actual sig can be found at the following URL:
http://user.xmission.com/~gazelle/Sigs/Aspergers
Giovanni <gfal...@inwind.it> wrote:
>On 8/15/23 16:30, Kalevi Kolttonen wrote:
>> On Unix, it used to be the case that only
>> NUL-characters and '/' were out of question. I
>> suppose some filesystems place more restrictions
>> on filenames nowadays.
>
>There are still no restriction on file names. It`s only a problem of the
>program. If it expects a file name as input, it has to test if the
>argument passed is - in which case it reads from stdin. And, usually,
>this works even if the file system has in the current directory a file
>named -
>
>To use the file - you should pass it to the program as ./-
Yes, as noted, you know that.
>On 8/15/23 16:30, Kalevi Kolttonen wrote:
>> On Unix, it used to be the case that only
>> NUL-characters and '/' were out of question. I
>> suppose some filesystems place more restrictions
>> on filenames nowadays.
>
>There are still no restriction on file names. It`s only a problem of the
>program. If it expects a file name as input, it has to test if the
>argument passed is - in which case it reads from stdin. And, usually,
>this works even if the file system has in the current directory a file
>named -
>
>To use the file - you should pass it to the program as ./-
And I know that.
And even Kalevi knows that.
But do they know that???
--
The randomly chosen signature file that would have appeared here is more than 4
lines long. As such, it violates one or more Usenet RFCs. In order to remain
in compliance with said RFCs, the actual sig can be found at the following URL:
Phil Carmody
Aug 15, 2023, 11:49:21 AM8/15/23
to
kal...@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
> 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.
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.
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.
Kalevi Kolttonen
Aug 15, 2023, 12:12:24 PM8/15/23
to
"They" probably don't know it. But let's face it,
nobody really wants to create a file having '-'
filename on purpose. The filename is not descriptive
at all, it would be just an insane choice for anything
useful.
It could happen by accident, but even that is quite
unlikely.
If "they" don't know how to delete it, there is no need
to panic. The file's existence does no harm. "They" can
always ask for help and someone will tell them how
to get rid of it.
I guess the stdin convention '-' is decades old.
It was chosen because they had pick something that
is short and not likely to exist as a real file.
br,
KK
nobody really wants to create a file having '-'
filename on purpose. The filename is not descriptive
at all, it would be just an insane choice for anything
useful.
It could happen by accident, but even that is quite
unlikely.
If "they" don't know how to delete it, there is no need
to panic. The file's existence does no harm. "They" can
always ask for help and someone will tell them how
to get rid of it.
I guess the stdin convention '-' is decades old.
It was chosen because they had pick something that
is short and not likely to exist as a real file.
br,
KK
Mut...@dastardlyhq.com
Aug 15, 2023, 12:15:09 PM8/15/23
to
On Tue, 15 Aug 2023 16:12:19 -0000 (UTC)
kal...@kolttonen.fi (Kalevi Kolttonen) wrote:
>Kenny McCormack <gaz...@shell.xmission.com> wrote:
>> But do they know that???
>
>"They" probably don't know it. But let's face it,
>nobody really wants to create a file having '-'
>filename on purpose. The filename is not descriptive
>at all, it would be just an insane choice for anything
>useful.
I used to think the same thing about spaces in filenames. Then along came
kal...@kolttonen.fi (Kalevi Kolttonen) wrote:
>Kenny McCormack <gaz...@shell.xmission.com> wrote:
>> But do they know that???
>
>"They" probably don't know it. But let's face it,
>nobody really wants to create a file having '-'
>filename on purpose. The filename is not descriptive
>at all, it would be just an insane choice for anything
>useful.
Windows.
Kalevi Kolttonen
Aug 15, 2023, 12:22:20 PM8/15/23
to
comparing two things that are very different.
The first one is just a way to name files or directories.
The second one is an age-old Unix convention that has
nothing to do with naming real files or directories.
It is best to not to confuse these two distinct ideas.
br,
KK
Kaz Kylheku
Aug 15, 2023, 1:33:46 PM8/15/23
to
in spite of there being spaces in file and directory names.
A program that handles - specially will not be confused when
that occurs in a path like /abc/-/def or ./- or -/ and other
possibilities.
Windows has worse problems, like issues if you try to make
a file called PRN in any directory.
"* Do not use the following reserved names for the name of a file:
CON, PRN, AUX, NUL, COM0, COM1, COM2, COM3, COM4, COM5, COM6, COM7,
COM8, COM9, LPT0, LPT1, LPT2, LPT3, LPT4, LPT5, LPT6, LPT7, LPT8,
and LPT9. Also avoid these names followed immediately by an
extension; for example, NUL.txt and NUL.tar.gz are both equivalent
to NUL. For more information, see Namespaces."
In Microsoft Teams, channel names cannot have MS-DOS device names:
https://learn.microsoft.com/en-us/microsoftteams/limits-specifications-teams
"Channel names can't contain the following characters or words:
[...]
Words forms, CON, CONIN$, CONOUT$, PRN, AUX, NUL, COM1 to COM9, LPT1
to LPT9, desktop.ini, _vti_
LOL ...
Joe Pfeiffer
Aug 15, 2023, 2:08:57 PM8/15/23
to
inadvertently run foo - xyz instead, ending up with a file named - and
one named xyz.
Richard Harnden
Aug 15, 2023, 2:50:49 PM8/15/23
to
Also:
$ >-f
$ >-r
$ rm *
How to safely cater for all 'weird' inputs?
Scott Lurndal
Aug 15, 2023, 4:16:25 PM8/15/23
to
the tool for that, when the tool is still useful.
Phil Carmody
Aug 15, 2023, 4:24:35 PM8/15/23
to
Phil Carmody
Aug 15, 2023, 4:48:19 PM8/15/23
to
filenames. Often used to hide things in plain sight on FTP sites, for
example.
MS Windows didn't allow spaces until Windows 95. I remember the Apple
advert at the time - it was a double-page spread which basically just
said:
C:\NGRTLTNS.W95
in a gajillion-point high font. I pulled that out of a newspaper and
had it on my wall at work. Not because I was an Apple fanboi, far
from it, but my disdain for all things MS Windows was already
entrenched, and I was being forced to use it for the not-the-actual-work
part of my job (which was on Sun workstations).
Lew Pitcher
Aug 15, 2023, 4:50:27 PM8/15/23
to
On Tue, 15 Aug 2023 23:24:28 +0300, Phil Carmody wrote:
> kal...@kolttonen.fi (Kalevi Kolttonen) writes:
>> Kenny McCormack <gaz...@shell.xmission.com> wrote:
>>> But do they know that???
>>
>> "They" probably don't know it. But let's face it,
>> nobody really wants to create a file having '-'
>> filename on purpose. The filename is not descriptive
>> at all, it would be just an insane choice for anything
>> useful.
>>
>> It could happen by accident, but even that is quite
>> unlikely.
>>
>> If "they" don't know how to delete it, there is no need
>> to panic. The file's existence does no harm. "They" can
>> always ask for help and someone will tell them how
>> to get rid of it.
>>
>> I guess the stdin convention '-' is decades old.
>> It was chosen because they had pick something that
>> is short and not likely to exist as a real file.
>
> I propose that '|' might have been better - it's even mnemonic.
But, '|' conflicts with the shell pipe character, and would need
> kal...@kolttonen.fi (Kalevi Kolttonen) writes:
>> Kenny McCormack <gaz...@shell.xmission.com> wrote:
>>> But do they know that???
>>
>> "They" probably don't know it. But let's face it,
>> nobody really wants to create a file having '-'
>> filename on purpose. The filename is not descriptive
>> at all, it would be just an insane choice for anything
>> useful.
>>
>> It could happen by accident, but even that is quite
>> unlikely.
>>
>> If "they" don't know how to delete it, there is no need
>> to panic. The file's existence does no harm. "They" can
>> always ask for help and someone will tell them how
>> to get rid of it.
>>
>> I guess the stdin convention '-' is decades old.
>> It was chosen because they had pick something that
>> is short and not likely to exist as a real file.
>
> I propose that '|' might have been better - it's even mnemonic.
a workaround in some cases. For example,
foo bar | blech
could either pipe stdout from foo (which processed bar) into
blech, or it could instruct foo to accept bar, stdin and blech
as inputs. And, unless you escape or singlequote the pipe character,
the pipe-command interpretation wins.
Similarly,
foo bar - blech
could either ask foo to read files "bar", "-" and "blech"
/or/ ask foo to read files "bar", stdin, and "blech",
depending on the presence (or absence) of a file named "-"
Again, the accepted method of discerning one from the other
is to modify that "-" to "./-", indicating a file (in the
current working directory) named "-".
So, pOHtato, pAHtato.
--
Lew Pitcher
"In Skills We Trust"
Ben Bacarisse
Aug 15, 2023, 10:20:39 PM8/15/23
to
kal...@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
> 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.
convention. It's never a "user" file, and anyone capable of creating it
should know how to remove it.
--
Ben.
James Kuyper
Aug 16, 2023, 1:37:22 AM8/16/23
to
...
two mechanisms: Copy-and-pasting a command line into a terminal window,
where a minor slip of the mouse resulted in the copy including far more
material than it was supposed to. Most of the resulting lines of text do
nothing, but every once in a while a line starts with a word that is a
valid unix command name, and some very weird things happen.
The second scenario is where someone stupidly gave an ordinary text file
execute permission, and someone else accidentally typed the name of that
file in a context where it would invoke the supposed "executable". The
results were similar to those from the copy-and-past problem, except
that some of the text files were much longer, increasing the chance of a
line from the file actually resulting in non-trivial behavior.
>> The interesction of:
>>
>> - Users who make filenames like "-foo" and "monthly forecast.xls"
>>
>> - Users who sit in a POSIX shell expanding wildcards like *
>> in the same directory.
>>
>> is probababy vanishingly nil, and the subset of those who do the
>> above in the same directory is even smaller.
>
> The cases I’ve encountered are where someone accidentally creates a file
> with a weird name (starts with - or whatever) and then has trouble
> deleting it. I don’t think they got as far as having accidents with
> wildcards in the cases I remember, but the basic setup of a file with a
> ridiculous name and a non-expert user does happen occasionally.
The most bizarre filenames I've seen were generally created by one of
>>
>> - Users who make filenames like "-foo" and "monthly forecast.xls"
>>
>> - Users who sit in a POSIX shell expanding wildcards like *
>> in the same directory.
>>
>> is probababy vanishingly nil, and the subset of those who do the
>> above in the same directory is even smaller.
>
> The cases I’ve encountered are where someone accidentally creates a file
> with a weird name (starts with - or whatever) and then has trouble
> deleting it. I don’t think they got as far as having accidents with
> wildcards in the cases I remember, but the basic setup of a file with a
> ridiculous name and a non-expert user does happen occasionally.
two mechanisms: Copy-and-pasting a command line into a terminal window,
where a minor slip of the mouse resulted in the copy including far more
material than it was supposed to. Most of the resulting lines of text do
nothing, but every once in a while a line starts with a word that is a
valid unix command name, and some very weird things happen.
The second scenario is where someone stupidly gave an ordinary text file
execute permission, and someone else accidentally typed the name of that
file in a context where it would invoke the supposed "executable". The
results were similar to those from the copy-and-past problem, except
that some of the text files were much longer, increasing the chance of a
line from the file actually resulting in non-trivial behavior.
vallor
Aug 16, 2023, 2:34:37 AM8/16/23
to
On Tue, 15 Aug 2023 19:50:44 +0100, Richard Harnden
<richard...@gmail.com> wrote in <ubghe4$2ubhu$1...@dont-email.me>:
(wondering if this belongs in comp.unix.shell, but here goes:)
In the 90's and maybe the early 2000's, many of our
(large installation) servers had a '-i' file in their
root directories. I'm not sure how widespread the
practice was, but I don't think we invented it.
--
-v
<richard...@gmail.com> wrote in <ubghe4$2ubhu$1...@dont-email.me>:
In the 90's and maybe the early 2000's, many of our
(large installation) servers had a '-i' file in their
root directories. I'm not sure how widespread the
practice was, but I don't think we invented it.
--
-v
Richard Harnden
Aug 16, 2023, 4:32:28 AM8/16/23
to
rm: .tmp: No such file or directory
$ unrm
-ksh: unrm: not found
$ man cpio
David Brown
Aug 16, 2023, 7:14:37 AM8/16/23
to
make certain files sort at the top or bottom of a list by prefixing with
odd characters (such as a space - that's always fun).
Many punctuation marks that are easy to use in gui programs are awkward
on the command line - brackets, quotation marks, ampersand, etc. Mostly
you can handle them on the command line by using quotation marks, or
backslash escapes.
Phil Carmody
Aug 16, 2023, 10:11:37 AM8/16/23
to
Lew Pitcher <lew.p...@digitalfreehold.ca> writes:
> On Tue, 15 Aug 2023 23:24:28 +0300, Phil Carmody wrote:
>> kal...@kolttonen.fi (Kalevi Kolttonen) writes:
>>> Kenny McCormack <gaz...@shell.xmission.com> wrote:
>>>> But do they know that???
>>>
>>> "They" probably don't know it. But let's face it,
>>> nobody really wants to create a file having '-'
>>> filename on purpose. The filename is not descriptive
>>> at all, it would be just an insane choice for anything
>>> useful.
>>>
>>> It could happen by accident, but even that is quite
>>> unlikely.
>>>
>>> If "they" don't know how to delete it, there is no need
>>> to panic. The file's existence does no harm. "They" can
>>> always ask for help and someone will tell them how
>>> to get rid of it.
>>>
>>> I guess the stdin convention '-' is decades old.
>>> It was chosen because they had pick something that
>>> is short and not likely to exist as a real file.
>>
>> 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
> On Tue, 15 Aug 2023 23:24:28 +0300, Phil Carmody wrote:
>> kal...@kolttonen.fi (Kalevi Kolttonen) writes:
>>> Kenny McCormack <gaz...@shell.xmission.com> wrote:
>>>> But do they know that???
>>>
>>> "They" probably don't know it. But let's face it,
>>> nobody really wants to create a file having '-'
>>> filename on purpose. The filename is not descriptive
>>> at all, it would be just an insane choice for anything
>>> useful.
>>>
>>> It could happen by accident, but even that is quite
>>> unlikely.
>>>
>>> If "they" don't know how to delete it, there is no need
>>> to panic. The file's existence does no harm. "They" can
>>> always ask for help and someone will tell them how
>>> to get rid of it.
>>>
>>> I guess the stdin convention '-' is decades old.
>>> It was chosen because they had pick something that
>>> is short and not likely to exist as a real file.
>>
>> 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,
special to make use of it?
Phil Carmody
Aug 16, 2023, 10:43:35 AM8/16/23
to
done by someone (who was at elevated privs at the time):
# rm *>o
(For those in exotic-keyboard-land: '>' was shifted '.', thus the
shift required for '*' hadn't been released yet.)
Lew Pitcher
Aug 16, 2023, 11:25:16 AM8/16/23
to
On Wed, 16 Aug 2023 17:11:28 +0300, Phil Carmody wrote:
> Lew Pitcher <lew.p...@digitalfreehold.ca> writes:
>> On Tue, 15 Aug 2023 23:24:28 +0300, Phil Carmody wrote:
[snip]
> Lew Pitcher <lew.p...@digitalfreehold.ca> writes:
>> On Tue, 15 Aug 2023 23:24:28 +0300, Phil Carmody wrote:
>>>> 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:
>>>> It was chosen because they had pick something that
>>>> is short and not likely to exist as a real file.
>>>
>>> I propose that '|' might have been better - it's even mnemonic.
>>
>> But, '|' conflicts with the shell pipe character, and would need
>> a workaround in some cases. For example,
>
> It's doing something special, why wouldn't you expect to do something
> special to make use of it?
For Unix shells, the < character indicates redirection of stdin.
I propose that '<' might have been a better choice as a standard
program option to flag "read from stdin" than either '|' /or/ '-'
were. :-)
Richard Kettlewell
Aug 16, 2023, 12:39:22 PM8/16/23
to
Scott Lurndal
Aug 16, 2023, 1:38:00 PM8/16/23
to
treated as regular characters in single quotes, for example.
Kenny McCormack
Aug 16, 2023, 1:43:27 PM8/16/23
to
In article <TP7DM.428701$U3w1....@fx09.iad>,
--
Treating the stock market indexes as general measures of the well-being of a
society is like treating your blood pressure as an indicator of health. The
higher, the better, right? In fact, a high stock market is good for the investor
class, but it means the rest of us are getting screwed better than ever.
Scott Lurndal <sl...@pacbell.net> wrote:
>Richard Kettlewell <inv...@invalid.invalid> writes:
>>David Brown <david...@hesbynett.no> writes:
>>> On 15/08/2023 09:50, Richard Kettlewell wrote:
>>>> The cases Ive encountered are where someone accidentally creates a
>Richard Kettlewell <inv...@invalid.invalid> writes:
>>David Brown <david...@hesbynett.no> writes:
>>> On 15/08/2023 09:50, Richard Kettlewell wrote:
>>>> file with a weird name (starts with - or whatever) and then has
>>>> trouble deleting it. I dont think they got as far as having
>>>> accidents with wildcards in the cases I remember, but the basic setup
>>>> of a file with a ridiculous name and a non-expert user does happen
>>>> occasionally.
>>>
>>> It's usually sufficient just to put the awkward name inside
>>> quotation marks.
>>
>>In the case we started with, quoting is not sufficient.
>
>Doesn't that depend on the type of quote? glob characters (*, ?) are
>treated as regular characters in single quotes, for example.
You're missing the point.
>>>> of a file with a ridiculous name and a non-expert user does happen
>>>> occasionally.
>>>
>>> It's usually sufficient just to put the awkward name inside
>>> quotation marks.
>>
>>In the case we started with, quoting is not sufficient.
>
>Doesn't that depend on the type of quote? glob characters (*, ?) are
>treated as regular characters in single quotes, for example.
--
Treating the stock market indexes as general measures of the well-being of a
society is like treating your blood pressure as an indicator of health. The
higher, the better, right? In fact, a high stock market is good for the investor
class, but it means the rest of us are getting screwed better than ever.
Spiros Bousbouras
Aug 16, 2023, 3:22:42 PM8/16/23
to
filename starts with - .Quoting isn't going to help with that.
Kaz Kylheku
Aug 16, 2023, 3:29:15 PM8/16/23
to
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.
Kaz Kylheku
Aug 16, 2023, 4:10:44 PM8/16/23
to
arguments are literal even if they look like options".
It's a token-level quote. The "--" token escapes a following "-rf"
token, and others after it.
Kaz Kylheku
Aug 16, 2023, 4:11:32 PM8/16/23
to
On 2023-08-16, Kaz Kylheku <864-11...@kylheku.com> wrote:
> On 2023-08-16, Spiros Bousbouras <spi...@gmail.com> wrote:
>> On Wed, 16 Aug 2023 17:37:55 GMT
>> sc...@slp53.sl.home (Scott Lurndal) wrote:
>>> Richard Kettlewell <inv...@invalid.invalid> writes:
>>> >David Brown <david...@hesbynett.no> writes:
>>> >> On 15/08/2023 09:50, Richard Kettlewell wrote:
>>> >>> The cases I’ve encountered are where someone accidentally creates a
>>> >>> file with a weird name (starts with - or whatever) and then has
>>> >>> trouble deleting it. I don’t think they got as far as having
>>> >>> accidents with wildcards in the cases I remember, but the basic setup
>>> >>> of a file with a ridiculous name and a non-expert user does happen
>>> >>> occasionally.
>>> >>
>>> >> It's usually sufficient just to put the awkward name inside quotation marks.
>>> >
>>> >In the case we started with, quoting is not sufficient.
>>>
>>> Doesn't that depend on the type of quote? glob characters (*, ?) are
>>> treated as regular characters in single quotes, for example.
>>
>> The issue is whether a filename may be confused for an option if the
>> filename starts with - .Quoting isn't going to help with that.
>
> It does. There is a quoting mechanism -- which says "the following
> arguments are literal even if they look like options".
>
> It's a token-level quote. The "--" token escapes a following "-rf"
> token, and others after it.
Ah, but of course, that is of no help with -, which is a non-option
> On 2023-08-16, Spiros Bousbouras <spi...@gmail.com> wrote:
>> On Wed, 16 Aug 2023 17:37:55 GMT
>> sc...@slp53.sl.home (Scott Lurndal) wrote:
>>> Richard Kettlewell <inv...@invalid.invalid> writes:
>>> >David Brown <david...@hesbynett.no> writes:
>>> >> On 15/08/2023 09:50, Richard Kettlewell wrote:
>>> >>> The cases I’ve encountered are where someone accidentally creates a
>>> >>> file with a weird name (starts with - or whatever) and then has
>>> >>> trouble deleting it. I don’t think they got as far as having
>>> >>> accidents with wildcards in the cases I remember, but the basic setup
>>> >>> of a file with a ridiculous name and a non-expert user does happen
>>> >>> occasionally.
>>> >>
>>> >> It's usually sufficient just to put the awkward name inside quotation marks.
>>> >
>>> >In the case we started with, quoting is not sufficient.
>>>
>>> Doesn't that depend on the type of quote? glob characters (*, ?) are
>>> treated as regular characters in single quotes, for example.
>>
>> The issue is whether a filename may be confused for an option if the
>> filename starts with - .Quoting isn't going to help with that.
>
> It does. There is a quoting mechanism -- which says "the following
> arguments are literal even if they look like options".
>
> It's a token-level quote. The "--" token escapes a following "-rf"
> token, and others after it.
argument.
Keith Thompson
Aug 16, 2023, 4:35:49 PM8/16/23
to
single or doublle quotes.
The difference is that * and ? are expanded by the shell, so the
invoked command never sees them, but arguments starting with -
are treated specially by the command itself.
If you have a file named *, you can delete it with `rm '*'` or
`rm "*"`, or `rm \*`.
If you have a file named -r, you can delete it with `rm ./-r`, or
`rm -- -r` if your rm implementation supports that (POSIX doesn't
specify it).
--
Keith Thompson (The_Other_Keith) Keith.S.T...@gmail.com
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */
Mut...@dastardlyhq.com
Aug 17, 2023, 6:26:47 AM8/17/23
to
On Tue, 15 Aug 2023 16:22:16 -0000 (UTC)
kal...@kolttonen.fi (Kalevi Kolttonen) wrote:
>In comp.unix.programmer Mut...@dastardlyhq.com wrote:
>> On Tue, 15 Aug 2023 16:12:19 -0000 (UTC)
>> kal...@kolttonen.fi (Kalevi Kolttonen) wrote:
>>>Kenny McCormack <gaz...@shell.xmission.com> wrote:
>>>> But do they know that???
>>>
>>>"They" probably don't know it. But let's face it,
>>>nobody really wants to create a file having '-'
>>>filename on purpose. The filename is not descriptive
>>>at all, it would be just an insane choice for anything
>>>useful.
>>
>> I used to think the same thing about spaces in filenames. Then along came
>> Windows.
>
>Filenames having spaces versus the stdin convention '-' is
>comparing two things that are very different.
>
>The first one is just a way to name files or directories.
>
>The second one is an age-old Unix convention that has
>nothing to do with naming real files or directories.
>
>It is best to not to confuse these two distinct ideas.
They both cause problems.
>In comp.unix.programmer Mut...@dastardlyhq.com wrote:
>> On Tue, 15 Aug 2023 16:12:19 -0000 (UTC)
>> kal...@kolttonen.fi (Kalevi Kolttonen) wrote:
>>>Kenny McCormack <gaz...@shell.xmission.com> wrote:
>>>> But do they know that???
>>>
>>>"They" probably don't know it. But let's face it,
>>>nobody really wants to create a file having '-'
>>>filename on purpose. The filename is not descriptive
>>>at all, it would be just an insane choice for anything
>>>useful.
>>
>> I used to think the same thing about spaces in filenames. Then along came
>> Windows.
>
>Filenames having spaces versus the stdin convention '-' is
>comparing two things that are very different.
>
>The first one is just a way to name files or directories.
>
>The second one is an age-old Unix convention that has
>nothing to do with naming real files or directories.
>
>It is best to not to confuse these two distinct ideas.
Mut...@dastardlyhq.com
Aug 17, 2023, 6:32:39 AM8/17/23
to
On Tue, 15 Aug 2023 23:32:22 +0300
Phil Carmody <pc+u...@asdf.org> wrote:
>Mut...@dastardlyhq.com writes:
>> On Tue, 15 Aug 2023 16:12:19 -0000 (UTC)
>> kal...@kolttonen.fi (Kalevi Kolttonen) wrote:
>>>Kenny McCormack <gaz...@shell.xmission.com> wrote:
>>>> But do they know that???
>>>
>>>"They" probably don't know it. But let's face it,
>>>nobody really wants to create a file having '-'
>>>filename on purpose. The filename is not descriptive
>>>at all, it would be just an insane choice for anything
>>>useful.
>>
>> I used to think the same thing about spaces in filenames. Then along came
>> Windows.
>
>Your memory if flawed. Spaces were always allowed in unix
>filenames. Often used to hide things in plain sight on FTP sites, for
>example.
Any character from 0-255 is allowed in unix filenames but only an idiot would
Phil Carmody <pc+u...@asdf.org> wrote:
>Mut...@dastardlyhq.com writes:
>> On Tue, 15 Aug 2023 16:12:19 -0000 (UTC)
>> kal...@kolttonen.fi (Kalevi Kolttonen) wrote:
>>>Kenny McCormack <gaz...@shell.xmission.com> wrote:
>>>> But do they know that???
>>>
>>>"They" probably don't know it. But let's face it,
>>>nobody really wants to create a file having '-'
>>>filename on purpose. The filename is not descriptive
>>>at all, it would be just an insane choice for anything
>>>useful.
>>
>> I used to think the same thing about spaces in filenames. Then along came
>> Windows.
>
>Your memory if flawed. Spaces were always allowed in unix
>filenames. Often used to hide things in plain sight on FTP sites, for
>example.
use spaces and non printing characters.
>MS Windows didn't allow spaces until Windows 95. I remember the Apple
So what?
It has become a standard in windows to use spaces in filenames no doubt due
to the hopeless command line interface so there was no necessity to play nice
with command line tools that by default use whitespace as field seperators.
>had it on my wall at work. Not because I was an Apple fanboi, far
>from it, but my disdain for all things MS Windows was already
>entrenched, and I was being forced to use it for the not-the-actual-work
>part of my job (which was on Sun workstations).
unless you use wildcards on the command line when suddenly case matters again.
Hopeless.
eg:
fenris$ touch HELLO
fenris$ ls hello
hello
fenris$ ls H*
HELLO
fenris$ ls h*
ls: h*: No such file or directory
Phil Carmody
Aug 17, 2023, 7:49:37 AM8/17/23
to
Lew Pitcher <lew.p...@digitalfreehold.ca> writes:
> On Wed, 16 Aug 2023 17:11:28 +0300, Phil Carmody wrote:
>> Lew Pitcher <lew.p...@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
> On Wed, 16 Aug 2023 17:11:28 +0300, Phil Carmody wrote:
>> Lew Pitcher <lew.p...@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. :-)
logic is absolutely equivalent?
Phil Carmody
Aug 17, 2023, 7:52:05 AM8/17/23
to
sc...@slp53.sl.home (Scott Lurndal) writes:
> Richard Kettlewell <inv...@invalid.invalid> writes:
>>David Brown <david...@hesbynett.no> writes:
>>> On 15/08/2023 09:50, Richard Kettlewell wrote:
>>>> The cases I’ve encountered are where someone accidentally creates a
> Richard Kettlewell <inv...@invalid.invalid> writes:
>>David Brown <david...@hesbynett.no> writes:
>>> On 15/08/2023 09:50, Richard Kettlewell wrote:
>>>> file with a weird name (starts with - or whatever) and then has
>>>> trouble deleting it. I don’t think they got as far as having
>>>> accidents with wildcards in the cases I remember, but the basic setup
>>>> of a file with a ridiculous name and a non-expert user does happen
>>>> occasionally.
>>>
>>> It's usually sufficient just to put the awkward name inside quotation marks.
>>
>>In the case we started with, quoting is not sufficient.
>
> Doesn't that depend on the type of quote? glob characters (*, ?) are
> treated as regular characters in single quotes, for example.
No, it depends on the program you intend to pass the filename to, and
>>>> of a file with a ridiculous name and a non-expert user does happen
>>>> occasionally.
>>>
>>> It's usually sufficient just to put the awkward name inside quotation marks.
>>
>>In the case we started with, quoting is not sufficient.
>
> Doesn't that depend on the type of quote? glob characters (*, ?) are
> treated as regular characters in single quotes, for example.
how it treats its arguments.
Which we don't know. So we can't say anything more at the moment.
Phil Carmody
Aug 17, 2023, 7:57:51 AM8/17/23
to
quoted, that's frightening. Thanks for reminding me why my installation
of linux on my Apple G5 box wasn't moment too soon. How can people live
with such wrongthink? Stockholm Syndrome?
Mind geboggled,
Geoff Clare
Aug 17, 2023, 8:41:07 AM8/17/23
to
Keith Thompson wrote:
> If you have a file named -r, you can delete it with `rm ./-r`, or
> `rm -- -r` if your rm implementation supports that (POSIX doesn't
> specify it).
POSIX does specify that "rm -- -r" removes a file called -r.
> If you have a file named -r, you can delete it with `rm ./-r`, or
> `rm -- -r` if your rm implementation supports that (POSIX doesn't
> specify it).
Almost all the utilities have a statement under OPTIONS that they
conform to XBD 12.2 Utility Syntax Guidelines (in some cases with
exceptions for specific individual guidelines). The requirement to
support "--" is guideline 10.
--
Geoff Clare <net...@gclare.org.uk>
Geoff Clare
Aug 17, 2023, 9:11:08 AM8/17/23
to
Phil Carmody wrote:
> Mut...@dastardlyhq.com writes:
>>
>> Apple arguably are even worse right now - case aware but case insensitive
>> unless you use wildcards on the command line when suddenly case matters again.
>> Hopeless.
>>
>> eg:
>> fenris$ touch HELLO
>> fenris$ ls hello
>> hello
>> fenris$ ls H*
>> HELLO
>> fenris$ ls h*
>> ls: h*: No such file or directory
>
> That I didn't know. Wow - if that's an actual interactive session being
> quoted, that's frightening. Thanks for reminding me why my installation
> of linux on my Apple G5 box wasn't moment too soon. How can people live
> with such wrongthink?
They don't have to: they can configure the filesystem that contains
their home directory to be properly case sensitive.
I have access to an ancient MacBook which is configured that way:
$ uname -sr
Darwin 15.4.0
$ touch HELLO
$ ls hello
ls: hello: No such file or directory
$ ls H*
HELLO
Geoff Clare <net...@gclare.org.uk>
> Mut...@dastardlyhq.com writes:
>>
>> Apple arguably are even worse right now - case aware but case insensitive
>> unless you use wildcards on the command line when suddenly case matters again.
>> Hopeless.
>>
>> eg:
>> fenris$ touch HELLO
>> fenris$ ls hello
>> hello
>> fenris$ ls H*
>> HELLO
>> fenris$ ls h*
>> ls: h*: No such file or directory
>
> That I didn't know. Wow - if that's an actual interactive session being
> quoted, that's frightening. Thanks for reminding me why my installation
> of linux on my Apple G5 box wasn't moment too soon. How can people live
> with such wrongthink?
their home directory to be properly case sensitive.
I have access to an ancient MacBook which is configured that way:
$ uname -sr
Darwin 15.4.0
$ touch HELLO
$ ls hello
ls: hello: No such file or directory
$ ls H*
HELLO
$ ls h*
ls: h*: No such file or directory
--
ls: h*: No such file or directory
Geoff Clare <net...@gclare.org.uk>
Kaz Kylheku
Aug 17, 2023, 9:52:28 AM8/17/23
to
On 2023-08-17, Mut...@dastardlyhq.com <Mut...@dastardlyhq.com> wrote:
> Any character from 0-255 is allowed in unix filenames but only an idiot would
> use spaces and non printing characters.
That's simply false. 0 is the null terminator and is not actually part
> Any character from 0-255 is allowed in unix filenames but only an idiot would
> use spaces and non printing characters.
of the name. The path-component-separating slash cannot be contained in
a path component; there is no escape mechanism to include it.
POSIX defines a set of characters which are recommended for use in file
names for portability; it is wise for applications and users to stick to
that.
Kenny McCormack
Aug 17, 2023, 10:09:53 AM8/17/23
to
In article <87ttsxz...@fatphil.org>,
Phil Carmody <pc+u...@asdf.org> wrote:
...
is like buying a BMW, ripping out the engine, and changing it into a go-kart.
Now, before you think I'm some Apple Fanboy, let me assure you that just
the opposite is true. I run all Linux, but I consider it wrong to pay more
than $100 for the box upon which I run Linux. That's why I'm all Raspberry
Pi nowadays.
But if you've paid Apple's exhorbitant fee to buy their hardware, then you
might as well be running their OS. I don't want to have to dot all the I's
and cross all the T's on this, but I assume you get what I mean. If you
like Linux, you should not be paying Apple prices for your hardware.
Or, to put it another way, Apple stuff (hardware and software) is for
people who like that sort of thing. And they do indeed like it.
By the way, the car analogy is not accidental. I believe that the more you
pay for a car, the more problems you will have with it. You are literally
paying for the problems. And again, there are people who like that. So,
again, paying lots for a car is for people who like that sort of thing.
And they do indeed like it.
--
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/IceCream
Phil Carmody <pc+u...@asdf.org> wrote:
...
>> ls: h*: No such file or directory
>
>That I didn't know. Wow - if that's an actual interactive session being
>quoted, that's frightening. Thanks for reminding me why my installation
>of linux on my Apple G5 box wasn't moment too soon. How can people live
>with such wrongthink? Stockholm Syndrome?
Kinda hate to disagree with ya there, but running Linux on Apple hardware
>
>That I didn't know. Wow - if that's an actual interactive session being
>quoted, that's frightening. Thanks for reminding me why my installation
>of linux on my Apple G5 box wasn't moment too soon. How can people live
>with such wrongthink? Stockholm Syndrome?
is like buying a BMW, ripping out the engine, and changing it into a go-kart.
Now, before you think I'm some Apple Fanboy, let me assure you that just
the opposite is true. I run all Linux, but I consider it wrong to pay more
than $100 for the box upon which I run Linux. That's why I'm all Raspberry
Pi nowadays.
But if you've paid Apple's exhorbitant fee to buy their hardware, then you
might as well be running their OS. I don't want to have to dot all the I's
and cross all the T's on this, but I assume you get what I mean. If you
like Linux, you should not be paying Apple prices for your hardware.
Or, to put it another way, Apple stuff (hardware and software) is for
people who like that sort of thing. And they do indeed like it.
By the way, the car analogy is not accidental. I believe that the more you
pay for a car, the more problems you will have with it. You are literally
paying for the problems. And again, there are people who like that. So,
again, paying lots for a car is for people who like that sort of thing.
And they do indeed like it.
--
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/IceCream
Kalevi Kolttonen
Aug 17, 2023, 10:23:24 AM8/17/23
to
In comp.unix.programmer Mut...@dastardlyhq.com wrote:
> They both cause problems.
So do nuclear bombs and fentynyl, yet they have
not enough in common to make a sensible comparison
between them.
Similar reasoning applies to filenames with spaces
and the '-' stdin convention. Many people like
the former and are justified in doing so, but
nobody has the desire to use '-' as a filename.
I am tired of making this obvious point over and
over, so if it does not sink in now, I have to
give up.
br,
KK
> They both cause problems.
So do nuclear bombs and fentynyl, yet they have
not enough in common to make a sensible comparison
between them.
Similar reasoning applies to filenames with spaces
and the '-' stdin convention. Many people like
the former and are justified in doing so, but
nobody has the desire to use '-' as a filename.
I am tired of making this obvious point over and
over, so if it does not sink in now, I have to
give up.
br,
KK
Mut...@dastardlyhq.com
Aug 17, 2023, 11:14:08 AM8/17/23
to
On Thu, 17 Aug 2023 14:57:44 +0300
>quoted, that's frightening. Thanks for reminding me why my installation
>of linux on my Apple G5 box wasn't moment too soon. How can people live
>with such wrongthink? Stockholm Syndrome?
I bought a Mac because I wanted a unix box that I could just switch on and
get coding rather than mess about installing some linux distro and hope the
bits all work. Plus MacOS has a bonus of lots of high quality apps on the
App Store. Though tbh if Solaris workstations were still a thing I'd have bought
one of them instead.
Phil Carmody <pc+u...@asdf.org> wrote:
>Mut...@dastardlyhq.com writes:
>> Apple arguably are even worse right now - case aware but case insensitive
>> unless you use wildcards on the command line when suddenly case matters
>again.
>> Hopeless.
>>
>> eg:
>> fenris$ touch HELLO
>> fenris$ ls hello
>> hello
>> fenris$ ls H*
>> HELLO
>> fenris$ ls h*
>> ls: h*: No such file or directory
>
>That I didn't know. Wow - if that's an actual interactive session being
It is, its a cut and paste from the terminal.
>Mut...@dastardlyhq.com writes:
>> Apple arguably are even worse right now - case aware but case insensitive
>> unless you use wildcards on the command line when suddenly case matters
>again.
>> Hopeless.
>>
>> eg:
>> fenris$ touch HELLO
>> fenris$ ls hello
>> hello
>> fenris$ ls H*
>> HELLO
>> fenris$ ls h*
>> ls: h*: No such file or directory
>
>That I didn't know. Wow - if that's an actual interactive session being
>quoted, that's frightening. Thanks for reminding me why my installation
>of linux on my Apple G5 box wasn't moment too soon. How can people live
>with such wrongthink? Stockholm Syndrome?
get coding rather than mess about installing some linux distro and hope the
bits all work. Plus MacOS has a bonus of lots of high quality apps on the
App Store. Though tbh if Solaris workstations were still a thing I'd have bought
one of them instead.
Mut...@dastardlyhq.com
Aug 17, 2023, 11:15:29 AM8/17/23
to
On Thu, 17 Aug 2023 13:49:49 +0100
Geoff Clare <ge...@clare.See-My-Signature.invalid> wrote:
>Phil Carmody wrote:
>
>> Mut...@dastardlyhq.com writes:
>>>
>>> Apple arguably are even worse right now - case aware but case insensitive
>>> unless you use wildcards on the command line when suddenly case matters
>again.
>>> Hopeless.
>>>
>>> eg:
>>> fenris$ touch HELLO
>>> fenris$ ls hello
>>> hello
>>> fenris$ ls H*
>>> HELLO
>>> fenris$ ls h*
>>> ls: h*: No such file or directory
>>
>> That I didn't know. Wow - if that's an actual interactive session being
>> quoted, that's frightening. Thanks for reminding me why my installation
>> of linux on my Apple G5 box wasn't moment too soon. How can people live
>> with such wrongthink?
>
>They don't have to: they can configure the filesystem that contains
>their home directory to be properly case sensitive.
You can, but it can break a lot of programs that expect case insensitivity.
Geoff Clare <ge...@clare.See-My-Signature.invalid> wrote:
>Phil Carmody wrote:
>
>> Mut...@dastardlyhq.com writes:
>>>
>>> Apple arguably are even worse right now - case aware but case insensitive
>>> unless you use wildcards on the command line when suddenly case matters
>again.
>>> Hopeless.
>>>
>>> eg:
>>> fenris$ touch HELLO
>>> fenris$ ls hello
>>> hello
>>> fenris$ ls H*
>>> HELLO
>>> fenris$ ls h*
>>> ls: h*: No such file or directory
>>
>> That I didn't know. Wow - if that's an actual interactive session being
>> quoted, that's frightening. Thanks for reminding me why my installation
>> of linux on my Apple G5 box wasn't moment too soon. How can people live
>> with such wrongthink?
>
>They don't have to: they can configure the filesystem that contains
>their home directory to be properly case sensitive.
Mut...@dastardlyhq.com
Aug 17, 2023, 11:22:22 AM8/17/23
to
On Thu, 17 Aug 2023 13:52:23 -0000 (UTC)
Kaz Kylheku <864-11...@kylheku.com> wrote:
>On 2023-08-17, Mut...@dastardlyhq.com <Mut...@dastardlyhq.com> wrote:
>> Any character from 0-255 is allowed in unix filenames but only an idiot would
>
>> use spaces and non printing characters.
>
>That's simply false. 0 is the null terminator and is not actually part
>of the name. The path-component-separating slash cannot be contained in
>a path component; there is no escape mechanism to include it.
Ok, there are a couple of exceptions. Point still stands.
Kaz Kylheku <864-11...@kylheku.com> wrote:
>On 2023-08-17, Mut...@dastardlyhq.com <Mut...@dastardlyhq.com> wrote:
>> Any character from 0-255 is allowed in unix filenames but only an idiot would
>
>> use spaces and non printing characters.
>
>That's simply false. 0 is the null terminator and is not actually part
>of the name. The path-component-separating slash cannot be contained in
>a path component; there is no escape mechanism to include it.
>POSIX defines a set of characters which are recommended for use in file
>names for portability; it is wise for applications and users to stick to
>that.
on non UTF8 terminals.
Scott Lurndal
Aug 17, 2023, 11:25:07 AM8/17/23
to
on the point of a pin - the use of a single hyphen
to denote stdin will _never_ change, it is pointless
to assume otherwise.
Keith Thompson
Aug 17, 2023, 4:43:22 PM8/17/23
to
Kaz Kylheku <864-11...@kylheku.com> writes:
> On 2023-08-17, Mut...@dastardlyhq.com <Mut...@dastardlyhq.com> wrote:
>> Any character from 0-255 is allowed in unix filenames but only an idiot would
>> use spaces and non printing characters.
>
> That's simply false. 0 is the null terminator and is not actually part
> of the name. The path-component-separating slash cannot be contained in
> a path component; there is no escape mechanism to include it.
>
> POSIX defines a set of characters which are recommended for use in file
> names for portability; it is wise for applications and users to stick to
> that.
https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03.html#tag_03_282
> On 2023-08-17, Mut...@dastardlyhq.com <Mut...@dastardlyhq.com> wrote:
>> Any character from 0-255 is allowed in unix filenames but only an idiot would
>> use spaces and non printing characters.
>
> That's simply false. 0 is the null terminator and is not actually part
> of the name. The path-component-separating slash cannot be contained in
> a path component; there is no escape mechanism to include it.
>
> POSIX defines a set of characters which are recommended for use in file
> names for portability; it is wise for applications and users to stick to
> that.
A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
a b c d e f g h i j k l m n o p q r s t u v w x y z
0 1 2 3 4 5 6 7 8 9 . _ -
Ben Bacarisse
Aug 17, 2023, 4:52:11 PM8/17/23
to
Mut...@dastardlyhq.com writes:
> On Tue, 15 Aug 2023 23:32:22 +0300
> Phil Carmody <pc+u...@asdf.org> wrote:
>>Mut...@dastardlyhq.com writes:
>>> On Tue, 15 Aug 2023 16:12:19 -0000 (UTC)
>>> kal...@kolttonen.fi (Kalevi Kolttonen) wrote:
>>>>Kenny McCormack <gaz...@shell.xmission.com> wrote:
>>>>> But do they know that???
>>>>
>>>>"They" probably don't know it. But let's face it,
>>>>nobody really wants to create a file having '-'
>>>>filename on purpose. The filename is not descriptive
>>>>at all, it would be just an insane choice for anything
>>>>useful.
>>>
>>> I used to think the same thing about spaces in filenames. Then along came
>>> Windows.
>>
>>Your memory if flawed. Spaces were always allowed in unix
>>filenames. Often used to hide things in plain sight on FTP sites, for
>>example.
>
> Any character from 0-255 is allowed in unix filenames but only an idiot would
> use spaces and non printing characters.
To some extent it depends on the file system, and to some extent it's
> On Tue, 15 Aug 2023 23:32:22 +0300
> Phil Carmody <pc+u...@asdf.org> wrote:
>>Mut...@dastardlyhq.com writes:
>>> On Tue, 15 Aug 2023 16:12:19 -0000 (UTC)
>>> kal...@kolttonen.fi (Kalevi Kolttonen) wrote:
>>>>Kenny McCormack <gaz...@shell.xmission.com> wrote:
>>>>> But do they know that???
>>>>
>>>>"They" probably don't know it. But let's face it,
>>>>nobody really wants to create a file having '-'
>>>>filename on purpose. The filename is not descriptive
>>>>at all, it would be just an insane choice for anything
>>>>useful.
>>>
>>> I used to think the same thing about spaces in filenames. Then along came
>>> Windows.
>>
>>Your memory if flawed. Spaces were always allowed in unix
>>filenames. Often used to hide things in plain sight on FTP sites, for
>>example.
>
> Any character from 0-255 is allowed in unix filenames but only an idiot would
> use spaces and non printing characters.
down to the kernel, but I don't know of any Unix/FS combination that
permits 0 (null) bytes in file names. I can't see how it could work.
And almost all file systems will prohibit the use of / in a file name,
though I've heard you can trick NFS into taking it.
Some file systems (depending on mount options) can have complex rules
such as rejecting any name with an invalid UTF-8 sequence.
--
Ben.
Keith Thompson
Aug 17, 2023, 5:27:57 PM8/17/23
to
https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap12.html#tag_12_02
Phil Carmody
Aug 17, 2023, 5:55:32 PM8/17/23
to
gaz...@shell.xmission.com (Kenny McCormack) writes:
> In article <87ttsxz...@fatphil.org>,
> Phil Carmody <pc+u...@asdf.org> wrote:
> ...
>>> ls: h*: No such file or directory
>>
>>That I didn't know. Wow - if that's an actual interactive session being
>>quoted, that's frightening. Thanks for reminding me why my installation
>>of linux on my Apple G5 box wasn't moment too soon. How can people live
>>with such wrongthink? Stockholm Syndrome?
>
> Kinda hate to disagree with ya there, but running Linux on Apple hardware
> is like buying a BMW, ripping out the engine, and changing it into a go-kart.
>
> Now, before you think I'm some Apple Fanboy, let me assure you that just
> the opposite is true. I run all Linux, but I consider it wrong to pay more
> than $100 for the box upon which I run Linux. That's why I'm all Raspberry
> Pi nowadays.
>
> But if you've paid Apple's exhorbitant fee to buy their hardware, then you
> might as well be running their OS.
Hahahah. Nah, never paid a penny. It was a "sponsorship" from Apple.
> In article <87ttsxz...@fatphil.org>,
> Phil Carmody <pc+u...@asdf.org> wrote:
> ...
>>> ls: h*: No such file or directory
>>
>>That I didn't know. Wow - if that's an actual interactive session being
>>quoted, that's frightening. Thanks for reminding me why my installation
>>of linux on my Apple G5 box wasn't moment too soon. How can people live
>>with such wrongthink? Stockholm Syndrome?
>
> Kinda hate to disagree with ya there, but running Linux on Apple hardware
> is like buying a BMW, ripping out the engine, and changing it into a go-kart.
>
> Now, before you think I'm some Apple Fanboy, let me assure you that just
> the opposite is true. I run all Linux, but I consider it wrong to pay more
> than $100 for the box upon which I run Linux. That's why I'm all Raspberry
> Pi nowadays.
>
> But if you've paid Apple's exhorbitant fee to buy their hardware, then you
> might as well be running their OS.
Top of the range kit at the time too. All I had to do was write fast
code and not insult them in public. Managed for several years.
Oh - my code ran faster under linux than OSX. The apple compiler seemed
to never want to use all 32 of the FP registers (and, more bizarrely,
the register it would mysteriously forget existed wasn't always the same
one). I later worked for Freescale and had access to their internal
tools, and could see how good or bad a job the various compilers were at
keeping the pipelines full, and it was clear that Apple weren't as smart
as they thought they were.
David Brown
Aug 18, 2023, 5:17:12 AM8/18/23
to
On 17/08/2023 16:09, Kenny McCormack wrote:
> In article <87ttsxz...@fatphil.org>,
> Phil Carmody <pc+u...@asdf.org> wrote:
> ...
>>> ls: h*: No such file or directory
>>
>> That I didn't know. Wow - if that's an actual interactive session being
>> quoted, that's frightening. Thanks for reminding me why my installation
>> of linux on my Apple G5 box wasn't moment too soon. How can people live
>> with such wrongthink? Stockholm Syndrome?
>
> Kinda hate to disagree with ya there, but running Linux on Apple hardware
> is like buying a BMW, ripping out the engine, and changing it into a go-kart.
>
> Now, before you think I'm some Apple Fanboy, let me assure you that just
> the opposite is true. I run all Linux, but I consider it wrong to pay more
> than $100 for the box upon which I run Linux. That's why I'm all Raspberry
> Pi nowadays.
>
> But if you've paid Apple's exhorbitant fee to buy their hardware, then you
> might as well be running their OS. I don't want to have to dot all the I's
> and cross all the T's on this, but I assume you get what I mean. If you
> like Linux, you should not be paying Apple prices for your hardware.
>
> Or, to put it another way, Apple stuff (hardware and software) is for
> people who like that sort of thing. And they do indeed like it.
>
I disagree completely.
> In article <87ttsxz...@fatphil.org>,
> Phil Carmody <pc+u...@asdf.org> wrote:
> ...
>>> ls: h*: No such file or directory
>>
>> That I didn't know. Wow - if that's an actual interactive session being
>> quoted, that's frightening. Thanks for reminding me why my installation
>> of linux on my Apple G5 box wasn't moment too soon. How can people live
>> with such wrongthink? Stockholm Syndrome?
>
> Kinda hate to disagree with ya there, but running Linux on Apple hardware
> is like buying a BMW, ripping out the engine, and changing it into a go-kart.
>
> Now, before you think I'm some Apple Fanboy, let me assure you that just
> the opposite is true. I run all Linux, but I consider it wrong to pay more
> than $100 for the box upon which I run Linux. That's why I'm all Raspberry
> Pi nowadays.
>
> But if you've paid Apple's exhorbitant fee to buy their hardware, then you
> might as well be running their OS. I don't want to have to dot all the I's
> and cross all the T's on this, but I assume you get what I mean. If you
> like Linux, you should not be paying Apple prices for your hardware.
>
> Or, to put it another way, Apple stuff (hardware and software) is for
> people who like that sort of thing. And they do indeed like it.
>
Apple made good quality hardware, with a style that many people like.
(I personally do not, and have never owned anything Apple.) Sure, you
pay a premium for it, but that's the case for a lot of hardware - if you
draw a graph of processor speed against processor price, you'll easily
see a point where you pay a lot of extra cash for a very small increase
in price. Yet for some people, that large increase is worth it.
So your Apple hardware might be twice the price for a 10% thinner and
lighter laptop. But if that's what you want, go for it - just as it is
fine to want far lower prices and accept slower or weaker hardware.
Then if someone decides that they want the Apple hardware, they've got
the money, they have no moral qualms about paying the high markup Apple
charges (some people have strong opinions about that kind of thing),
that's fine - they've bought the Apple hardware.
And if they decide that they prefer Linux (or Windows) to MacOS, then
installing their preferred system makes the system better - it increases
the value to them. It would be absurd to use an OS that is inferior (at
least in that person's view) just because they had paid for it! You
would not expect a Linux fan to use the Windows installation that comes
with most off-the-shelf PC's - why would you expect them to use MacOS ?
Case in point - Linus Torvalds used a MacBook running Linux as his main
PC for a while, because the hardware (the screen in particular) was
better than alternative laptops.
David Brown
Aug 18, 2023, 5:28:39 AM8/18/23
to
On 17/08/2023 15:52, Kaz Kylheku wrote:
> On 2023-08-17, Mut...@dastardlyhq.com <Mut...@dastardlyhq.com> wrote:
>> Any character from 0-255 is allowed in unix filenames but only an idiot would
>> use spaces and non printing characters.
Only an idiot would think one rule fits all use-cases.
> On 2023-08-17, Mut...@dastardlyhq.com <Mut...@dastardlyhq.com> wrote:
>> Any character from 0-255 is allowed in unix filenames but only an idiot would
>> use spaces and non printing characters.
>
> That's simply false. 0 is the null terminator and is not actually part
> of the name. The path-component-separating slash cannot be contained in
> a path component; there is no escape mechanism to include it.
>
> POSIX defines a set of characters which are recommended for use in file
> names for portability; it is wise for applications and users to stick to
> that.
>
hand.
If you are making software that will be shared amongst a wide variety of
systems, stick to ASCII letters, digits, and underscore - that will work
on everything, including Windows.
If you are writing a document in Thai that will be read by Thai speakers
on Thai computers, name the document in Thai using Thai script.
It's not hard to handle "complicated" filenames from the command line,
outside a few pathological cases (like "-"). Sensible filenames are
fine, even with spaces, brackets, or non-ASCII letters. If those
features are helpful to the main use of the names for the files in
question, use them. If they are unhelpful, don't use them.
Thus it makes sense to avoid inconvenient characters in the names and
paths of programs, and you'll very rarely want them in program source
code names or directories. But they are common and useful for things
like document filenames.
Phil Carmody
Aug 19, 2023, 6:33:33 AM8/19/23
to
Ben Bacarisse <ben.u...@bsb.me.uk> writes:
> Some file systems (depending on mount options) can have complex rules
> such as rejecting any name with an invalid UTF-8 sequence.
Oooh, now I'm tempted to name files in Latin-1, to deliberately break
> Some file systems (depending on mount options) can have complex rules
> such as rejecting any name with an invalid UTF-8 sequence.
filesystems that make such assumptions!
Oğuz
Aug 19, 2023, 9:15:38 AM8/19/23
to
On 8/19/23 1:33 PM, Phil Carmody wrote:
> Ben Bacarisse <ben.u...@bsb.me.uk> writes:
>> Some file systems (depending on mount options) can have complex rules
>> such as rejecting any name with an invalid UTF-8 sequence.
>
> Oooh, now I'm tempted to name files in Latin-1, to deliberately break
> filesystems that make such assumptions!
Be careful with that attitude. The "memory-safe" sudo replacement
> Ben Bacarisse <ben.u...@bsb.me.uk> writes:
>> Some file systems (depending on mount options) can have complex rules
>> such as rejecting any name with an invalid UTF-8 sequence.
>
> Oooh, now I'm tempted to name files in Latin-1, to deliberately break
> filesystems that make such assumptions!
doesn't support non-UTF-8 input either:
https://github.com/memorysafety/sudo-rs/issues/213
Mut...@dastardlyhq.com
Aug 19, 2023, 10:48:12 AM8/19/23
to
On Sat, 19 Aug 2023 16:15:32 +0300
=?UTF-8?B?T8SfdXo=?= <oguzism...@gmail.com> wrote:
>On 8/19/23 1:33 PM, Phil Carmody wrote:
>> Ben Bacarisse <ben.u...@bsb.me.uk> writes:
>>> Some file systems (depending on mount options) can have complex rules
>>> such as rejecting any name with an invalid UTF-8 sequence.
>>
>> Oooh, now I'm tempted to name files in Latin-1, to deliberately break
>> filesystems that make such assumptions!
>Be careful with that attitude. The "memory-safe" sudo replacement
>doesn't support non-UTF-8 input either:
Whats memory unsafe about sudo?
=?UTF-8?B?T8SfdXo=?= <oguzism...@gmail.com> wrote:
>On 8/19/23 1:33 PM, Phil Carmody wrote:
>> Ben Bacarisse <ben.u...@bsb.me.uk> writes:
>>> Some file systems (depending on mount options) can have complex rules
>>> such as rejecting any name with an invalid UTF-8 sequence.
>>
>> Oooh, now I'm tempted to name files in Latin-1, to deliberately break
>> filesystems that make such assumptions!
>Be careful with that attitude. The "memory-safe" sudo replacement
>doesn't support non-UTF-8 input either:
Ben Bacarisse
Aug 19, 2023, 4:14:51 PM8/19/23
to
Phil Carmody <pc+u...@asdf.org> writes:
> Ben Bacarisse <ben.u...@bsb.me.uk> writes:
>> Some file systems (depending on mount options) can have complex rules
>> such as rejecting any name with an invalid UTF-8 sequence.
>
> Oooh, now I'm tempted to name files in Latin-1, to deliberately break
> filesystems that make such assumptions!
Why?
> Ben Bacarisse <ben.u...@bsb.me.uk> writes:
>> Some file systems (depending on mount options) can have complex rules
>> such as rejecting any name with an invalid UTF-8 sequence.
>
> Oooh, now I'm tempted to name files in Latin-1, to deliberately break
> filesystems that make such assumptions!
--
Ben.
Kalevi Kolttonen
Aug 19, 2023, 10:02:24 PM8/19/23
to
Anyway, one cannot "break" those filesystems as the
invalid names are simply rejected. I am not 100%
sure but ZFS might be an instance of such a filesystem.
br,
KK
Scott Lurndal
Aug 20, 2023, 1:24:52 PM8/20/23
to
Mut...@dastardlyhq.com
Aug 20, 2023, 3:21:54 PM8/20/23
to
Rainer Weikusat
Aug 20, 2023, 4:57:41 PM8/20/23
to
that's conjectured to be bug free in this respect by Really Wishful
Thinking[tm] is supposed to prevent simple memory access errors C
supports.
Kenny McCormack
Aug 20, 2023, 6:33:55 PM8/20/23
to
In article <87lee55...@doppelsaurus.mobileactivedefense.com>,
Rainer Weikusat <rwei...@talktalk.net> wrote:
...
Preumably one in which word order doesn't matter.
--
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/Reaganomics
Rainer Weikusat <rwei...@talktalk.net> wrote:
...
>It's not written in a language whose extremely complicate runtime
>system that's conjectured to be bug free in this respect by Really
>Wishful Thinking[tm] is supposed to prevent simple memory access errors
>C supports.
What language was this quoted paragraph written in?
>system that's conjectured to be bug free in this respect by Really
>Wishful Thinking[tm] is supposed to prevent simple memory access errors
>C supports.
Preumably one in which word order doesn't matter.
--
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:
Scott Lurndal
Aug 20, 2023, 9:26:41 PM8/20/23
to
gaz...@shell.xmission.com (Kenny McCormack) writes:
>In article <87lee55...@doppelsaurus.mobileactivedefense.com>,
>Rainer Weikusat <rwei...@talktalk.net> wrote:
>...
>>It's not written in a language whose extremely complicate runtime
>>system that's conjectured to be bug free in this respect by Really
>>Wishful Thinking[tm] is supposed to prevent simple memory access errors
>>C supports.
>
>What language was this quoted paragraph written in?
>
>Preumably one in which word order doesn't matter.
Word order in German and English don't always agree.
>In article <87lee55...@doppelsaurus.mobileactivedefense.com>,
>Rainer Weikusat <rwei...@talktalk.net> wrote:
>...
>>It's not written in a language whose extremely complicate runtime
>>system that's conjectured to be bug free in this respect by Really
>>Wishful Thinking[tm] is supposed to prevent simple memory access errors
>>C supports.
>
>What language was this quoted paragraph written in?
>
>Preumably one in which word order doesn't matter.
Basically he is saying, somewhat mockingly, that because it is
not written in Rust, sudo written in C is inherently memory unsafe.
Kenny McCormack
Aug 20, 2023, 10:57:26 PM8/20/23
to
In article <g3zEM.718458$AsA.1...@fx18.iad>,
OK, thanks.
I am glad that you were able to intuit that "Rust" was "the other language"
involved in the comparison.
--
They say compassion is a virtue, but I don't have the time!
- David Byrne -
I am glad that you were able to intuit that "Rust" was "the other language"
involved in the comparison.
--
They say compassion is a virtue, but I don't have the time!
- David Byrne -
Mut...@dastardlyhq.com
Aug 21, 2023, 2:50:08 AM8/21/23
to
they call it) anyway, so its no safer than C/C++ in these circumstances.
Rainer Weikusat
Aug 21, 2023, 12:17:00 PM8/21/23
to
gaz...@shell.xmission.com (Kenny McCormack) writes:
> In article <g3zEM.718458$AsA.1...@fx18.iad>,
> Scott Lurndal <sl...@pacbell.net> wrote:
>>gaz...@shell.xmission.com (Kenny McCormack) writes:
>>>In article <87lee55...@doppelsaurus.mobileactivedefense.com>,
>>>Rainer Weikusat <rwei...@talktalk.net> wrote:
>>>...
>>>>It's not written in a language whose extremely complicate runtime
>>>>system that's conjectured to be bug free in this respect by Really
>>>>Wishful Thinking[tm] is supposed to prevent simple memory access errors
>>>>C supports.
>>>
>>>What language was this quoted paragraph written in?
>>>
>>>Preumably one in which word order doesn't matter.
>>
>>Word order in German and English don't always agree.
>>
>>Basically he is saying, somewhat mockingly, that because it is
>>not written in Rust, sudo written in C is inherently memory unsafe.
>
> OK, thanks.
>
> I am glad that you were able to intuit that "Rust" was "the other language"
> involved in the comparison.
That's pretty obvious from the
> In article <g3zEM.718458$AsA.1...@fx18.iad>,
> Scott Lurndal <sl...@pacbell.net> wrote:
>>gaz...@shell.xmission.com (Kenny McCormack) writes:
>>>In article <87lee55...@doppelsaurus.mobileactivedefense.com>,
>>>Rainer Weikusat <rwei...@talktalk.net> wrote:
>>>...
>>>>It's not written in a language whose extremely complicate runtime
>>>>system that's conjectured to be bug free in this respect by Really
>>>>Wishful Thinking[tm] is supposed to prevent simple memory access errors
>>>>C supports.
>>>
>>>What language was this quoted paragraph written in?
>>>
>>>Preumably one in which word order doesn't matter.
>>
>>Word order in German and English don't always agree.
>>
>>Basically he is saying, somewhat mockingly, that because it is
>>not written in Rust, sudo written in C is inherently memory unsafe.
>
> OK, thanks.
>
> I am glad that you were able to intuit that "Rust" was "the other language"
> involved in the comparison.
,----
| Be careful with that attitude. The "memory-safe" sudo replacement
| doesn't support non-UTF-8 input either:
|
| https://github.com/memorysafety/sudo-rs/issues/213
| doesn't support non-UTF-8 input either:
|
`----
upthread. Rust is conjectured to be memory safe because people using it
really want to believe that the Rust runtime - some orders of magnitude
more complicated than a real lot of C programs - has not such bugs.
Kenny McCormack
Aug 21, 2023, 3:10:24 PM8/21/23
to
In article <87v8d8j...@doppelsaurus.mobileactivedefense.com>,
personally.
--
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/Seriously
>,----
>| Be careful with that attitude. The "memory-safe" sudo replacement
>| doesn't support non-UTF-8 input either:
>|
>| https://github.com/memorysafety/sudo-rs/issues/213
>`----
That URL means nothing to me. But that's just me. Don't take it
>| Be careful with that attitude. The "memory-safe" sudo replacement
>| doesn't support non-UTF-8 input either:
>|
>| https://github.com/memorysafety/sudo-rs/issues/213
>`----
personally.
--
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:
Rainer Weikusat
Aug 21, 2023, 3:31:56 PM8/21/23
to
gaz...@shell.xmission.com (Kenny McCormack) writes:
> In article <87v8d8j...@doppelsaurus.mobileactivedefense.com>,
> Rainer Weikusat <rwei...@talktalk.net> wrote:
> ...
>>,----
>>| Be careful with that attitude. The "memory-safe" sudo replacement
>>| doesn't support non-UTF-8 input either:
>>|
>>| https://github.com/memorysafety/sudo-rs/issues/213
>>`----
>
> That URL means nothing to me. But that's just me. Don't take it
> personally.
In this case, I suggest one of two options
> In article <87v8d8j...@doppelsaurus.mobileactivedefense.com>,
> Rainer Weikusat <rwei...@talktalk.net> wrote:
> ...
>>,----
>>| Be careful with that attitude. The "memory-safe" sudo replacement
>>| doesn't support non-UTF-8 input either:
>>|
>>| https://github.com/memorysafety/sudo-rs/issues/213
>>`----
>
> That URL means nothing to me. But that's just me. Don't take it
> personally.
1) You'll try to memorize that rs commonly means Rust. Eg, it's usually
the extension used for Rust source files.
2) You'll ask your full-time carer to click on the link for you and read
the content of the page to you.
In either case, posting more lame flames into this groups for no
conceivable reason is not going to improve your understanding of
anything.
Kenny McCormack
Aug 21, 2023, 4:29:54 PM8/21/23
to
In article <87r0nwj...@doppelsaurus.mobileactivedefense.com>,
Rainer Weikusat <rwei...@talktalk.net> wrote:
>blah, blah, blah
I told you not to take it personally, but what do you go and do?
All I can say is that I tried to help you and to steer you in the right
direction.
--
Men rarely (if ever) manage to dream up a God superior to themselves.
Most Gods have the manners and morals of a spoiled child.
Rainer Weikusat <rwei...@talktalk.net> wrote:
>blah, blah, blah
I told you not to take it personally, but what do you go and do?
All I can say is that I tried to help you and to steer you in the right
direction.
--
Men rarely (if ever) manage to dream up a God superior to themselves.
Most Gods have the manners and morals of a spoiled child.
Rainer Weikusat
Aug 21, 2023, 4:48:45 PM8/21/23
to
gaz...@shell.xmission.com (Kenny McCormack) writes:
> In article <87r0nwj...@doppelsaurus.mobileactivedefense.com>,
> Rainer Weikusat <rwei...@talktalk.net> wrote:
>>blah, blah, blah
>
> I told you not to take it personally, but what do you go and do?
I'm principally interested in technical discussions, eg, about Rust and
> In article <87r0nwj...@doppelsaurus.mobileactivedefense.com>,
> Rainer Weikusat <rwei...@talktalk.net> wrote:
>>blah, blah, blah
>
> I told you not to take it personally, but what do you go and do?
memory safety, and sometimes motivated to try my hands at minimally
creative flames when people are trying to play the Most Importinant
Dickhead with the help of the usual boilerplate phrases.
0 new messages