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

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

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

Cheers,
Gary B-)

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

The interesction of:

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

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

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

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

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

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

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

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

[...]

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

Kaz Kylheku <864-117-4973@kylheku.com> writes:
> On 2023-08-15, Gary R. Schmidt <grschmidt@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.

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

The usual example of an ‘admin script’ that has to deal with bizarre
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/

In article <wwvleeceobt.fsf@LkoBDZeT.terraraq.uk>,
Richard Kettlewell <invalid@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
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.

On 15/08/2023 09:50, Richard Kettlewell wrote:
> Kaz Kylheku <864-117-4973@kylheku.com> writes:
>> On 2023-08-15, Gary R. Schmidt <grschmidt@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.

In comp.unix.programmer Gary R. Schmidt <grschmidt@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
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.

That is a terrible and unjustified comparison
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

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

Ciao
Giovanni
--
A computer is like an air conditioner,
it stops working when you open Windows.
< https://giovanni.homelinux.net/ >

In article <ubg4no$8kb$1@milena.home.net.it>,
Giovanni <gfalzoni@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.

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

kalevi@kolttonen.fi (Kalevi Kolttonen) writes:
> The "problem" of having '-' as a filename is
> a complete non-issue that only has theoretical
> interest. On Unix, no matter which stdin
> convention you choose, you run the risk of
> someone having that convention as a filename.

Not everything is a valid filename in unix. If you can exclude the
possibility of accepting a directory, then you could have adopted
something that could only be a directory as the placeholder, such as
'.', or '/', or '-/', or .... Ooof, technically you could use '',
as that's a forbidden filename too, but I'm not suggesting that.

> On Unix, it used to be the case that only
> NUL-characters and '/' were out of question. I
> suppose some filesystems place more restrictions
> on filenames nowadays.

There are many contexts where certain characters have special meanings,
and so it makes sense to avoid them in filenames (colons spring to mind,
but of course some shell characters). However, sense has never been a
proven property of the modern computer user. At least the order of
command processing is mostly sane, so that you can't use malicious
filenames to inject shell metacharacters into commandlines, it's only
the programs being executed that could get confused by what they
receive.

Phil
--
We are no longer hunters and nomads. No longer awed and frightened, as we have
gained some understanding of the world in which we live. As such, we can cast
aside childish remnants from the dawn of our civilization.
-- NotSanguine on SoylentNews, after Eugen Weber in /The Western Tradition/

Kenny McCormack <gazelle@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.

br,
KK

On Tue, 15 Aug 2023 16:12:19 -0000 (UTC)
kalevi@kolttonen.fi (Kalevi Kolttonen) wrote:
>Kenny McCormack <gazelle@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.