On Sun, 20 Aug 2023 17:24:46 GMT
scott@slp53.sl.home (Scott Lurndal) wrote:
>Muttley@dastardlyhq.com writes:
>>On Sat, 19 Aug 2023 16:15:32 +0300
>>=?UTF-8?B?T8SfdXo=?= <oguzismailuysal@gmail.com> wrote:
>>>On 8/19/23 1:33 PM, Phil Carmody wrote:
>>>> Ben Bacarisse <ben.usenet@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?
>>
>https://www.cisa.gov/news-events/alerts/2021/02/02/sudo-heap-based-buffer-overf
>low-vulnerability-cve-2021-3156

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

Muttley@dastardlyhq.com writes:
> On Sat, 19 Aug 2023 16:15:32 +0300
> =?UTF-8?B?T8SfdXo=?= <oguzismailuysal@gmail.com> wrote:
>>On 8/19/23 1:33 PM, Phil Carmody wrote:
>>> Ben Bacarisse <ben.usenet@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?

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.

In article <87lee55t51.fsf@doppelsaurus.mobileactivedefense.com>,
Rainer Weikusat <rweikusat@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.

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

gazelle@shell.xmission.com (Kenny McCormack) writes:
>In article <87lee55t51.fsf@doppelsaurus.mobileactivedefense.com>,
>Rainer Weikusat <rweikusat@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.

In article <g3zEM.718458$AsA.196497@fx18.iad>,
Scott Lurndal <slp53@pacbell.net> wrote:
>gazelle@shell.xmission.com (Kenny McCormack) writes:
>>In article <87lee55t51.fsf@doppelsaurus.mobileactivedefense.com>,
>>Rainer Weikusat <rweikusat@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.

--
They say compassion is a virtue, but I don't have the time!

- David Byrne -

On Mon, 21 Aug 2023 01:26:36 GMT
scott@slp53.sl.home (Scott Lurndal) wrote:
>gazelle@shell.xmission.com (Kenny McCormack) writes:
>>In article <87lee55t51.fsf@doppelsaurus.mobileactivedefense.com>,
>>Rainer Weikusat <rweikusat@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.

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

gazelle@shell.xmission.com (Kenny McCormack) writes:
> In article <g3zEM.718458$AsA.196497@fx18.iad>,
> Scott Lurndal <slp53@pacbell.net> wrote:
>>gazelle@shell.xmission.com (Kenny McCormack) writes:
>>>In article <87lee55t51.fsf@doppelsaurus.mobileactivedefense.com>,
>>>Rainer Weikusat <rweikusat@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

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

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

In article <87v8d8jrpo.fsf@doppelsaurus.mobileactivedefense.com>,
Rainer Weikusat <rweikusat@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.

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

gazelle@shell.xmission.com (Kenny McCormack) writes:
> In article <87v8d8jrpo.fsf@doppelsaurus.mobileactivedefense.com>,
> Rainer Weikusat <rweikusat@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

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.

In article <87r0nwjios.fsf@doppelsaurus.mobileactivedefense.com>,
Rainer Weikusat <rweikusat@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.

gazelle@shell.xmission.com (Kenny McCormack) writes:
> In article <87r0nwjios.fsf@doppelsaurus.mobileactivedefense.com>,
> Rainer Weikusat <rweikusat@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
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.

[ Followup-To: comp.unix.programmer ]

On Sun, 13 Aug 2023 06:42:17 -0700 (PDT)
Malcolm McLean <malcolm.arthur.mclean@gmail.com> wrote:
> On Unix-lke systems, what is the convention for putting a program into a
> mode where it accepts input from stdin?
> Where the user invokes it directly, he'll normally want input from a file. So
> the normal invocation would be
>
> myprogram myinput.txt
>
> But if he just types "myprogram" it should display brief help text. So we
> can't omit the filename to make the program read from stdin.

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

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

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

--
vlaho.ninja/prog

On Sun, 13 Aug 2023 07:07:55 -0700 (PDT)
Malcolm McLean <malcolm.arthur.mclean@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.
[...]
> > > So do you pass an option
> > >
> > > myprogram -stdin
> > >
> > > or what is the normal way of solving this?
> > - (a single dash) as argument. Even if the programme accepts multiple file
> > name arguments , a single dash among those means "read from stdin".
> >
> So conventionally the file name is "-"?

Yes.

In article <LtQSo3SOOU09AXJ1X@bongo-ra.co>,
Spiros Bousbouras <spibou@gmail.com> wrote:
....
>> So conventionally the file name is "-"?
>
>Yes.

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

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

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

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

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

Tremendously wet - from the standpoint of water.

On 2023-08-14, Kenny McCormack <gazelle@shell.xmission.com> wrote:
> In article <LtQSo3SOOU09AXJ1X@bongo-ra.co>,
> Spiros Bousbouras <spibou@gmail.com> wrote:
> ...
>>> So conventionally the file name is "-"?
>>
>>Yes.
>
> Yes, but, as indicated, it is just that - a convention. The program has to
> recognize it, and act accordingly. Note, incidentally, that it raises the
> question of "What if the user actually has a file named '-' ?"

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

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

In article <20230813200644.979@kylheku.com>,
Kaz Kylheku <864-117-4973@kylheku.com> wrote:
>On 2023-08-14, Kenny McCormack <gazelle@shell.xmission.com> wrote:
>> In article <LtQSo3SOOU09AXJ1X@bongo-ra.co>,
>> Spiros Bousbouras <spibou@gmail.com> wrote:
>> ...
>>>> So conventionally the file name is "-"?
>>>
>>>Yes.
>>
>> Yes, but, as indicated, it is just that - a convention. The program has to
>> recognize it, and act accordingly. Note, incidentally, that it raises the
>> question of "What if the user actually has a file named '-' ?"
>
>Then they write a path to reference it which doesn't look like "-",
>such as "./-".

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

--

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

- Thomas 'PointedEars' Lahn -

Spiros Bousbouras <spibou@gmail.com> writes:

> [ Followup-To: comp.unix.programmer ]
>
> On Sun, 13 Aug 2023 06:42:17 -0700 (PDT)
> Malcolm McLean <malcolm.arthur.mclean@gmail.com> wrote:
>> On Unix-lke systems, what is the convention for putting a program into a
>> mode where it accepts input from stdin?
>> Where the user invokes it directly, he'll normally want input from a file. So
>> the normal invocation would be
>>
>> myprogram myinput.txt
>>
>> But if he just types "myprogram" it should display brief help text. So we
>> can't omit the filename to make the program read from stdin.
>
> I would use a -h option for help text and with no arguments it should read
> from stdin .

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

>> So do you pass an option
>>
>> myprogram -stdin
>>
>> or what is the normal way of solving this?
>
> - (a single dash) as argument. Even if the programme accepts multiple file
> name arguments , a single dash among those means "read from stdin".

Yes, this is what seems common.

On 2023-08-14, Kenny McCormack wrote:

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

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

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

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

On Sun, 13 Aug 2023 21:26:59 -0600
Joe Pfeiffer <pfeiffer@cs.nmsu.edu> wrote:
> Spiros Bousbouras <spibou@gmail.com> writes:
>
> > [ Followup-To: comp.unix.programmer ]
> >
> > On Sun, 13 Aug 2023 06:42:17 -0700 (PDT)
> > Malcolm McLean <malcolm.arthur.mclean@gmail.com> wrote:
> >> On Unix-lke systems, what is the convention for putting a program into a
> >> mode where it accepts input from stdin?
> >> Where the user invokes it directly, he'll normally want input from a file. So
> >> the normal invocation would be
> >>
> >> myprogram myinput.txt
> >>
> >> But if he just types "myprogram" it should display brief help text. So we
> >> can't omit the filename to make the program read from stdin.
> >
> > I would use a -h option for help text and with no arguments it should read
> > from stdin .
>
> No, the typical user will expect help text from just typing the command
> name (notwithstanding ancient programs like cat). I typically treat no
> args the same as -h

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

Spiros Bousbouras <spibou@gmail.com> writes:

> On Sun, 13 Aug 2023 21:26:59 -0600
> Joe Pfeiffer <pfeiffer@cs.nmsu.edu> wrote:
>> Spiros Bousbouras <spibou@gmail.com> writes:
>>
>> > [ Followup-To: comp.unix.programmer ]
>> >
>> > On Sun, 13 Aug 2023 06:42:17 -0700 (PDT)
>> > Malcolm McLean <malcolm.arthur.mclean@gmail.com> wrote:
>> >> On Unix-lke systems, what is the convention for putting a program into a
>> >> mode where it accepts input from stdin?
>> >> Where the user invokes it directly, he'll normally want input from a file. So
>> >> the normal invocation would be
>> >>
>> >> myprogram myinput.txt
>> >>
>> >> But if he just types "myprogram" it should display brief help text. So we
>> >> can't omit the filename to make the program read from stdin.
>> >
>> > I would use a -h option for help text and with no arguments it should read
>> > from stdin .
>>
>> No, the typical user will expect help text from just typing the command
>> name (notwithstanding ancient programs like cat). I typically treat no
>> args the same as -h
>
> Not to mention grep , awk , sed , sort , bc , od , etc. Being "ancient"
> means that their conventions are more firmly established so why would a
> user expect something else ?

Agreed. And newer programs will follow the ancient convention. The
distinction, it seems to me, is not age but purpose. If you can easily
see a program being used in a pipeline, it should silently read stdin,
but if that usage is rare, it should interpret '-' as a convention for
reading stdin.

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

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

works as expected.

--
Ben.

In article <874jl1j4rh.fsf@bsb.me.uk>,
Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
....
>Agreed. And newer programs will follow the ancient convention. The
>distinction, it seems to me, is not age but purpose. If you can easily
>see a program being used in a pipeline, it should silently read stdin,

No. As I mentioned earlier, if "cat" (et al) was being designed today, it
wouldn't work like that.

Remember that, in the early days of Unix, typing commands on a 110 baud
teletype, keeping typing to an absolute minimum was a top priority. Today,
not so much.

--
The randomly chosen signature file that would have appeared here is more than 4
lines long. As such, it violates one or more Usenet RFCs. In order to remain
in compliance with said RFCs, the actual sig can be found at the following URL:
http://user.xmission.com/~gazelle/Sigs/FreeCollege

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

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

br,
KK

gazelle@shell.xmission.com (Kenny McCormack) writes:
>In article <874jl1j4rh.fsf@bsb.me.uk>,
>Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
>...
>>Agreed. And newer programs will follow the ancient convention. The
>>distinction, it seems to me, is not age but purpose. If you can easily
>>see a program being used in a pipeline, it should silently read stdin,
>
>No. As I mentioned earlier, if "cat" (et al) was being designed today, it
>wouldn't work like that.

Why do you believe that?

On 14/08/2023 16:41, Scott Lurndal wrote:
> gazelle@shell.xmission.com (Kenny McCormack) writes:
>> In article <874jl1j4rh.fsf@bsb.me.uk>,
>> Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
>> ...
>>> Agreed. And newer programs will follow the ancient convention. The
>>> distinction, it seems to me, is not age but purpose. If you can easily
>>> see a program being used in a pipeline, it should silently read stdin,
>>
>> No. As I mentioned earlier, if "cat" (et al) was being designed today, it
>> wouldn't work like that.
>
> Why do you believe that?
>

$ cat a.c b.c - <c.c >abc.c

What's not to love?

Richard Harnden <richard.nospam@gmail.com> writes:
>On 14/08/2023 16:41, Scott Lurndal wrote:
>> gazelle@shell.xmission.com (Kenny McCormack) writes:
>>> In article <874jl1j4rh.fsf@bsb.me.uk>,
>>> Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
>>> ...
>>>> Agreed. And newer programs will follow the ancient convention. The
>>>> distinction, it seems to me, is not age but purpose. If you can easily
>>>> see a program being used in a pipeline, it should silently read stdin,
>>>
>>> No. As I mentioned earlier, if "cat" (et al) was being designed today, it
>>> wouldn't work like that.
>>
>> Why do you believe that?
>>
>
>$ cat a.c b.c - <c.c >abc.c
>
>What's not to love?

Exactly.

$ nroff -mm docbody.mm | cat docheader.txt - doctrailer.txt > document