On 2/8/24 07:32, The Natural Philosopher wrote:
> Undertaking...

If we're being pedantic ...

> Moving away from uppercase DOS 6x.3x filenames was a step forward.

.... then it's 8.3 file names. ;-)

Grant. . . .

On 2/8/24 15:16, Carlos E.R. wrote:
> The point is, you never know what script or program may create or access
> a file of the same name but different case as another part of the
> program or another program. You can never be sure.

Yep.

> That's feasible. For a Samba share, it would be desirable, it can avoid
> trouble in Windows programs that expect case to not matter.

Samba (et al.) is (are) special case wherein the daemon does the case
folding, not the underlying file system.

IMHO this is the proper place to handle this type of conversion.

--
Grant. . . .

On 2/8/24 08:14, Richard Kettlewell wrote:
> However I don’t see Lawrence advocating doing it to whole system
> (i.e. /) so much as individual volumes or even directories.

Lawrence didn't give any indication on the scope of where the setting
would be used save for at the file system level and a vague reference to
a directory.

Without further guidance, it's natural to assume that it's the file
system mount point -> entire file system.

Combine that with the current Linux predilection of a single file system
for everything (monolithic root), and we end up at Lawrence very
potentially talking about doing this to root (/).

--
Grant. . . .

On 2/8/24 16:11, Lawrence D'Oliveiro wrote:
> That’s the opposite of what we’re discussing here.

No, it really isn't.

It's the same feature, just flipping it the other way.

This is a perfect example of how case confusion can bite or literally
break things.

--
Grant. . . .

On 2/8/24 18:39, Marc Olschok wrote:
> I did not know and in fact I cannot think of a situation where I
> would desire case-insensitivity.

I used it in the late '90s to host files on a Linux web server that had
been written to be hosted on a Windows web server. There were WAY TOO
MANY mixed case references to the same file. index.html != INDEX.HTML
!= InDeX.hTmL.

Enabling the feature on the Document Root for that site allowed the
Linux box to serve that site without any modifications.

> But of course it helps to be aware of this possibility just in case
> one runs into a system configured this way. Thanks.

I absolutely agree.

Be aware of things, even if you aren't cognizant of all the subtle
details. Know of it so that you can go research the details in the
future if you think you may need it for a problem at hand.

--
Grant. . . .

On Thu, 8 Feb 2024 18:52:08 -0600, Grant Taylor wrote:

> And if your system was using case insensitive files like you are
> suggesting and I arranged to put `SU` in a directory earlier in your
> path, you just ran a trojan when you mean to run `su`.

You can only do that if you have write access to that directory. If so,
why would you put “SU” rather than “su”?

On Thu, 8 Feb 2024 19:03:49 -0600, Grant Taylor wrote:

> What if someone has `.` as the first directory in their PATH

We decided that was a bad idea back in the last century.

On Thu, 8 Feb 2024 19:17:06 -0600, Grant Taylor wrote:

> On 2/8/24 16:11, Lawrence D'Oliveiro wrote:
>
>> That’s the opposite of what we’re discussing here.
>
> No, it really isn't.
>
> It's the same feature, just flipping it the other way.

Except it causes a problem one way that it doesn’t cause the other way.

On Thu, 8 Feb 2024 19:16:15 -0600, Grant Taylor wrote:

> ... a vague reference to a directory.

So you felt “You must enable case-insensitivity on the directories on
that volume where you want it (before putting anything in those
directories)” was not clear enough for you?

On 2/8/24 20:15, Lawrence D'Oliveiro wrote:
> We decided that was a bad idea back in the last century.

And yet people still do it.

There are a lot of bad ideas that people do or argue to do. Like
prefixing their PATH with "." or confusing case.

--
Grant. . . .

On 2/8/24 20:16, Lawrence D'Oliveiro wrote:
> Except it causes a problem one way that it doesn’t cause the other way.

Handling case in an unexpected way /always/ causes confusion. The only
question is how soon, not if.

--
Grant. . . .

On Thu, 8 Feb 2024 22:15:54 -0600, Grant Taylor wrote:

> On 2/8/24 20:15, Lawrence D'Oliveiro wrote:
>> We decided that was a bad idea back in the last century.
>
> And yet people still do it.

If they do it, it’s not clear what difference this option will make,
security-wise. Can you explain why it would make a difference?

On 2/8/24 20:17, Lawrence D'Oliveiro wrote:
> So you felt “You must enable case-insensitivity on the directories
> on that volume where you want it (before putting anything in those
> directories)” was not clear enough for you?

Obviously not.

If there's room for confusion in what you intended in this thread, just
think about how much room there is for confusion if someone handles case
in an unexpected way.

--
Grant. . . .

On 2/8/24 22:17, Lawrence D'Oliveiro wrote:
> If they do it, it’s not clear what difference this option will make,
> security-wise. Can you explain why it would make a difference?

Which option are you asking about; case confusion and / or prefixing
PATH with `.`?

PATH=/path/to/oracle/bin:/usr/local/bin:/usr/bin:/bin;~/bin:.

Which `su` will be run when an senior Oracle DBA has created the
following file:

/path/to/oracle/bin/SU

and a jr Oracle DBA runs `su`.

Does the junior Oracle DBA run /path/to/oracle/bin/SU or /bin/su?

Which command do you think the jr Oracle DBA was expecting to run? Was
it the command that actually ended up being run?

N.B. `su` is just a stand in. It can really be ANY command you want.
It could even be a wrapper that calls your least favorite editor emacs
instead of vi or vi instead of emacs. Or the cult of ed(1) may laugh
and drop you in the standard editor.

As for prefixing PATH with `.`, that's simply running a command in the
current working directory instead of somewhere else in your path.

What if said junior Oracle DBA happened to be in the /var/tmp directory
where someone decided to test a practical joke by creating a script
named `Su` that prints an obscene message on all consoles on the system?

Doing something to enable case confusion and prefixing PATH with a . are
a Bad Idea (TM).

--
Grant. . . .

On 2/8/24 20:13, Lawrence D'Oliveiro wrote:
> You can only do that if you have write access to that directory. If so,
> why would you put “SU” rather than “su”?

Does BOFH mean anything to you? Or what about practical jokes? Or
creating teachable moments.

Have you ever had anyone in your life let you do something you wish they
had stopped you from doing, but they wanted you to learn from?

There are many ways that commands can end up in directories in
unexpected ways; accidents, malicious intent, options that enable
confusion. Some are worse than others.

--
Grant. . . .

On Thu, 8 Feb 2024 22:30:59 -0600, Grant Taylor wrote:

> On 2/8/24 20:13, Lawrence D'Oliveiro wrote:
>
>> You can only do that if you have write access to that directory. If so,
>> why would you put “SU” rather than “su”?
>
> Does BOFH mean anything to you?

Nope.

On Thu, 8 Feb 2024 22:27:02 -0600, Grant Taylor wrote:

> On 2/8/24 22:17, Lawrence D'Oliveiro wrote:
>
>> If they do it, it’s not clear what difference this option will make,
>> security-wise. Can you explain why it would make a difference?
>
> Which option are you asking about; case confusion and / or prefixing
> PATH with `.`?

The supposed security-based reason why you object to case insensitivity.

On Thu, 8 Feb 2024 22:17:02 -0600, Grant Taylor wrote:

> On 2/8/24 20:16, Lawrence D'Oliveiro wrote:
>
>> Except it causes a problem one way that it doesn’t cause the other way.
>
> Handling case in an unexpected way /always/ causes confusion.

But the “confusion” only happens one way, not the other way.

On Thu, 8 Feb 2024 22:19:06 -0600, Grant Taylor wrote:

> On 2/8/24 20:17, Lawrence D'Oliveiro wrote:
>
>> So you felt “You must enable case-insensitivity on the directories on
>> that volume where you want it (before putting anything in those
>> directories)” was not clear enough for you?
>
> Obviously not.

Which part would you like clarified? The part about the option being
settable on a per-directory basis? The part where you have to specify
which directories you want to enable the option on? Or the part which says
that the option has to do with case insensitivity?

On 2/8/24 22:47, Lawrence D'Oliveiro wrote:
> Which part would you like clarified?

I don't want anything clarified.

You asked if your previous statement was clear.

I stated that it was obviously not clear because it was questioned.

You have since made it clear elsewhere.

But your previous statement was obviously not clear enough.

--
Grant. . . .

On 2/8/24 22:41, Lawrence D'Oliveiro wrote:
> But the “confusion” only happens one way, not the other way.

It happens both ways.

The computer does things that the human did not expect it to do, hence
confusion as to why it did so until they realize that the way the case
was handled caused the unexpected behavior.

Using mixed case in a case preserving way will not access the same file
and will likely return an error about file not found.

Using fixed case in a non-case preserving way can cause the wrong file
to be accessed.

Both problems -> confusion stem from inconsistent / unexpected use of case.

--
Grant. . . .

On 2/8/24 22:39, Lawrence D'Oliveiro wrote:
> Nope.

You should look it up.

I think they are funny stories.

--
Grant. . . .

On Thu, 8 Feb 2024 23:36:28 -0600, Grant Taylor wrote:

> On 2/8/24 22:41, Lawrence D'Oliveiro wrote:
>
>> But the “confusion” only happens one way, not the other way.
>
> It happens both ways.

Here’s what the OP said:

I once mistakenly added a case sensitive disk to an Apple OS/X
machine. Applications promptly stopped working.

Here’s what the OP didn’t say:

I once mistakenly added a case-insensitive disk to an Apple OS/X
machine. Applications promptly started working.

Do you see a difference? Need something clarified, perhaps? Try looking at
the words one by one.

On Thu, 8 Feb 2024 23:32:12 -0600, Grant Taylor wrote:

> On 2/8/24 22:47, Lawrence D'Oliveiro wrote:
>
>> Which part would you like clarified?
>
> I don't want anything clarified.
>
> You asked if your previous statement was clear.
>
> I stated that it was obviously not clear because it was questioned.

That’s not what you said. You said “vague reference to a directory”, not
that it was “questioned” anywhere.

> You have since made it clear elsewhere.

Back-pedalling, eh? Go on, deny it. Strenuously, even.

> But your previous statement was obviously not clear enough.

How come?

On Thu, 8 Feb 2024 23:37:08 -0600, Grant Taylor wrote:

> On 2/8/24 22:39, Lawrence D'Oliveiro wrote:
>
>> Nope.
>
> You should look it up.
>
> I think they are funny stories.

Hahaha ... nope.

Do you know what the term “red herring” means?