| Sysop: | Amessyroom |
|---|---|
| Location: | Fayetteville, NC |
| Users: | 28 |
| Nodes: | 6 (0 / 6) |
| Uptime: | 49:17:51 |
| Calls: | 422 |
| Files: | 1,024 |
| Messages: | 90,463 |
On Sun, 27 Apr 2025 10:21:55 +0000
Farley Flud <ff@linux.rocks> wrote:
We all should hate case insensitive file systems.
Why?
On Sun, 27 Apr 2025 10:21:55 +0000 Farley Flud <ff@linux.rocks> wrote:
We all should hate case insensitive file systems.
Why?
On Mon, 28 Apr 2025 08:00:14 -0700, John Ames wrote:
On Sun, 27 Apr 2025 10:21:55 +0000 Farley Flud <ff@linux.rocks> wrote:
We all should hate case insensitive file systems.
Why?
Apparently, because case folding is hard, and there are edge cases that
have no general case handling.
On 28 Apr 2025 17:49:48 GMT
rbowman <bowman@montana.com> wrote:
although that might be an argument for case insensitivity.
Just so, it seems to me. Of course it's many years too late for *nix to course-correct on this, but it was a stupid design decision in 1970 and
it remains stupid now. Well, such is the nature of things in this vale
of sin and tears...
On Sun, 27 Apr 2025 10:21:55 +0000
Farley Flud <ff@linux.rocks> wrote:
We all should hate case insensitive file systems.
Why?
["Followup-To:" header set to comp.os.linux.misc.]
On 2025-04-28, Farley Flud <ff@linux.rocks> wrote:
To paraphrase Kipling:
Unix is Unix and Microslop is Microslop and never the twain should
meet.
Consider when you move a file from a POSIX filesystem, to one which is
case insensitive, and you move it back. I've had digger.zip and
DIGGER.ZIP because one verison once resided on an MSDOS partition.
Issues arise when you interact with other systems which don't preserve
case. Or archivers that may not.
He is trollish. He does not read this group. He wants to promote flames
on the advocacy group.
On Tue, 29 Apr 2025 10:34:34 +0200, Carlos E.R. wrote:
He is trollish. He does not read this group. He wants to promote flames
on the advocacy group.
Who the fuck are you? A fucking fascist/communist?
Usenet is free and open to all, including what may be perceived
as "trolls" by myopic, unobjective, and highly biased posters like
you.
Disagree?
Then go and start your own "wordpress" or other blog where you
can pretend to be the BIG MAN.
In simpler terms:
Go and fuck yourself.
You mean either ß -> ẞ or ß -> SS don't you?
["Followup-To:" header set to comp.os.linux.misc.]
On 2025-04-28, Farley Flud <ff@linux.rocks> wrote:
On Mon, 28 Apr 2025 11:12:42 -0700, John Ames wrote:
Just so, it seems to me. Of course it's many years too late for *nix to
course-correct on this, but it was a stupid design decision in 1970 and
it remains stupid now. Well, such is the nature of things in this vale
of sin and tears...
Case insensitivity was only idiotic at the beginning, but now, in the
age of Unicode, it is supremely idiotic.
Consider the German "sharp s," which I cannot enter as UTF-8 here.
But the lower case sharp s maps into TWO DIFFERENT upper case chars:
<can't enter> and "SS," e.g. STRASSE or <can't enter>.
There are special rules on case folding for thousands of Unicode chars
and the "sharp s" example is one of the simplest.
What about the files:
cat_scan_links.html
CAT_scan_links.html
To paraphrase Kipling:
Unix is Unix and Microslop is Microslop and never the twain should
meet.
Consider when you move a file from a POSIX filesystem, to one which is
case insensitive, and you move it back. I've had digger.zip and
DIGGER.ZIP because one verison once resided on an MSDOS partition.
Issues arise when you interact with other systems which don't preserve
case. Or archivers that may not.
As for your file example though, you do demonstrate why one may choose
upper vs lower case, Windows does allow that. But should they be
*seperate* files? You are asking for trouble putting both files like
that in one directory. I'd never do it. The system lets you do it, but
you shouldn't.
However, I agree with your comment about unicode. Treating upper and
lower case letters as the same, leads to complicated rules, which may
vary from system to system, and cause chaos. Case sensitivity, perhaps
is the lesser of two evils here.
As for your file example though, you do demonstrate why one may choose
upper vs lower case, Windows does allow that. But should they be
*seperate* files?
However, I agree with your comment about unicode. Treating upper and
lower case letters as the same, leads to complicated rules, which may
vary from system to system, and cause chaos.
On Tue, 29 Apr 2025 14:18:48 -0000 (UTC), Borax Man wrote:
As for your file example though, you do demonstrate why one may choose
upper vs lower case, Windows does allow that. But should they be
*seperate* files?
It should be your choice.
However, I agree with your comment about unicode. Treating upper and
lower case letters as the same, leads to complicated rules, which may
vary from system to system, and cause chaos.
Unicode seems to have come up with some standard set of “default” rules that are independent of any particular localization setting.
On 2025-04-29, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
On Tue, 29 Apr 2025 14:18:48 -0000 (UTC), Borax Man wrote:Well, you get to choose the filesystem you use. JFS2 if I recall could
As for your file example though, you do demonstrate why one may choose
upper vs lower case, Windows does allow that. But should they be
*seperate* files?
It should be your choice.
be case insensitive, but i would play havoc with the OS if you used it
in the wron place. In Windows, can you make it case sensitive?
However, I agree with your comment about unicode. Treating upper and
lower case letters as the same, leads to complicated rules, which may
vary from system to system, and cause chaos.
Unicode seems to have come up with some standard set of “default” rules >> that are independent of any particular localization setting.
These would need to be in a standard, one that filesystems can
implement. But then filesystems would have to implement the same
standard, otherwise, again issues arise. Can't see this being workable
for end users.
As for case-sensitive file systems, I can live with them, although case-preserving (but insensitive) file systems would be a good
compromise for me.
So, in essence, the development of case-sensitive
systems ruined it for case-insensitive :-)
Same now for space-tolerant file names.
As for case-sensitive file systems, I can live with them, although case-preserving (but insensitive) file systems would be a good
compromise for me. Yes, I can distinguish between makefile and
Makefile, but if you start using multiple file names that differ
only in case... well, here there be dragons.
On 4/30/25 6:00 AM, Borax Man wrote:
On 2025-04-29, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
On Tue, 29 Apr 2025 14:18:48 -0000 (UTC), Borax Man wrote:Well, you get to choose the filesystem you use. JFS2 if I recall could
As for your file example though, you do demonstrate why one may choose >>>> upper vs lower case, Windows does allow that. But should they be
*seperate* files?
It should be your choice.
be case insensitive, but i would play havoc with the OS if you used it
in the wron place. In Windows, can you make it case sensitive?
However, I agree with your comment about unicode. Treating upper and
lower case letters as the same, leads to complicated rules, which may
vary from system to system, and cause chaos.
Unicode seems to have come up with some standard set of “default” rules >>> that are independent of any particular localization setting.
These would need to be in a standard, one that filesystems can
implement. But then filesystems would have to implement the same
standard, otherwise, again issues arise. Can't see this being workable
for end users.
So, in essence, the development of case-sensitive
systems ruined it for case-insensitive :-)
Same now for space-tolerant file names.
On Thu, 01 May 2025 04:45:59 GMT, Charlie Gibbs wrote:
As for case-sensitive file systems, I can live with them, although
case-preserving (but insensitive) file systems would be a good
compromise for me.
I’ve been wondering whether or not to take the plunge and create a case- insensitive ext4 volume on my Linux system, just for a certain categories
of files where I find it particularly irksome to remember which way they
were named (as per the way certain artists write their names).
I fully accept this is likely to lead to confusion between the parts of my filesystem where I have enabled case-insensitivity, and those parts where
I have not ...
But spaces in filenames cause me *far more* headaches. They are the
greater evil.
Anyone who writes code, or worse Regexp, knows that exact syntax
including case is de rigeur.
On Thu, 1 May 2025 13:42:36 -0000 (UTC), Borax Man wrote:
But spaces in filenames cause me *far more* headaches. They are the
greater evil.
The real evil was the mishmash of DOS and Windows that wound up with
'Program Files' becoming 'progra~1'.
I do regexps all the time. I appreciate the fact that the default
setting for searches in Emacs (for both plain strings and regexps) is to
be case- insensitive, unless the pattern/string includes a capital
letter, in which case it becomes case-sensitive.
rbowman <bowman@montana.com> wrote:
On Thu, 1 May 2025 13:42:36 -0000 (UTC), Borax Man wrote:
But spaces in filenames cause me *far more* headaches. They are the
greater evil.
The real evil was the mishmash of DOS and Windows that wound up with
'Program Files' becoming 'progra~1'.
I question the wisdom of Torvalds on this topic since he allowed
ext filesystems to have an even greater evil than either of those:
newlines in file names! Imagine if the average joe were exposed
to that capability - we'd have multi-paragraph file names to deal
with all over the place.
On 2025-05-01, Computer Nerd Kev wrote:
rbowman <bowman@montana.com> wrote:
On Thu, 1 May 2025 13:42:36 -0000 (UTC), Borax Man wrote:
But spaces in filenames cause me *far more* headaches. They are the
greater evil.
The real evil was the mishmash of DOS and Windows that wound up with
'Program Files' becoming 'progra~1'.
I question the wisdom of Torvalds on this topic since he allowed
ext filesystems to have an even greater evil than either of those:
newlines in file names! Imagine if the average joe were exposed
to that capability - we'd have multi-paragraph file names to deal
with all over the place.
But why should newlines not be allowed in file names? Last I checked (granted, that was many years ago), there is only one character which
usually needs to be excluded, \0. And then the path element separator is probably convenient to avoid.
Anything else, where and why would you
draw a line? And how would you avoid reaching the Windows situation
where there's a whole group of convenient glyphs that are not allowed?
(Or can that be disabled too in Windows NT?)
Back in the days of 8.3 file names, someone described the original Mac
as a machine where you could write a letter to Grandma in the file name.
But why should newlines not be allowed in file names?
Yes, but sooner or later you're going to get bit. We encountered a bug
in the sort routine used by Micro Focus COBOL. By default it created ridiculously small work files, so when we tried sorting a very large
file, the numeric portion of work file names (of the form "worknnn")
ran up to 999, wrapped around, and carried into the alphanumeric portion
-
which ran all the way up the ASCII chart, wrapped around to \0, and
worked up from there. After the inevitable crash, we had 12,000 work
files to get rid of, which had just about any character value in their
names.
What a mess.
I question the wisdom of Torvalds on this topic since he allowed ext filesystems to have an even greater evil than either of those:
newlines in file names!
rbowman <bowman@montana.com> wrote:
On Thu, 1 May 2025 13:42:36 -0000 (UTC), Borax Man wrote:
But spaces in filenames cause me *far more* headaches. They are the
greater evil.
The real evil was the mishmash of DOS and Windows that wound up with
'Program Files' becoming 'progra~1'.
I question the wisdom of Torvalds on this topic since he allowed
ext filesystems to have an even greater evil than either of those:
newlines in file names! Imagine if the average joe were exposed
to that capability - we'd have multi-paragraph file names to deal
with all over the place.
On Fri, 02 May 2025 00:15:50 GMT, Charlie Gibbs wrote:
We encountered a bug
in the sort routine used by Micro Focus COBOL. By default it created
ridiculously small work files, so when we tried sorting a very large
file, the numeric portion of work file names (of the form "worknnn")
ran up to 999, wrapped around, and carried into the alphanumeric portion
-
which ran all the way up the ASCII chart, wrapped around to \0, and
worked up from there. After the inevitable crash, we had 12,000 work
files to get rid of, which had just about any character value in their
names.
What a mess.
Weren’t they all in a temporary work directory?
On 2025-05-02, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
On Fri, 02 May 2025 00:15:50 GMT, Charlie Gibbs wrote:
We encountered a bug in the sort routine used by Micro Focus
COBOL. By default it created ridiculously small work files, so
when we tried sorting a very large file, the numeric portion of
work file names (of the form "worknnn") ran up to 999, wrapped
around, and carried into the alphanumeric portion - which ran all
the way up the ASCII chart, wrapped around to \0, and worked up
from there. After the inevitable crash, we had 12,000 work files
to get rid of, which had just about any character value in their
names. What a mess.
Weren’t they all in a temporary work directory?
Unfortunately, no.
On 2025-05-01, Computer Nerd Kev wrote:
rbowman <bowman@montana.com> wrote:
On Thu, 1 May 2025 13:42:36 -0000 (UTC), Borax Man wrote:
But spaces in filenames cause me *far more* headaches. They are the
greater evil.
The real evil was the mishmash of DOS and Windows that wound up with
'Program Files' becoming 'progra~1'.
I question the wisdom of Torvalds on this topic since he allowed
ext filesystems to have an even greater evil than either of those:
newlines in file names! Imagine if the average joe were exposed
to that capability - we'd have multi-paragraph file names to deal
with all over the place.
But why should newlines not be allowed in file names?
Anything else, where and why would you draw a line? And how would
you avoid reaching the Windows situation where there's a whole
group of convenient glyphs that are not allowed?
For one thing it makes shell scripting complicated ...
... and for another this is just really confusing ...
That (at least defaulting to that escaped/quoted output) was a recent
change in GNU ls, wasn't it?
On 2 May 2025 17:18:10 +1000, Computer Nerd Kev wrote:
For one thing it makes shell scripting complicated ...
This may be true of a straight POSIX shell, but there are techniques for coping with arbitrary filenames in Bash, just for example.
... and for another this is just really confusing ...
Just tried it:
ldo@theon:try> touch file1 file2$'\n'file3 file4
ldo@theon:try> ls -1
file1
'file2'$'\n''file3'
file4
ldo@theon:try> ls -1 --quoting-style=literal
file1
file2?file3
file4
ldo@theon:try> rm file*
ldo@theon:try> cd ..
ldo@theon:hack> rmdir try
Wasn’t so bad, was it?
I agree that SOME sane degree of rigor SHOULD be
applied to file names. They're too basic, meaning
too many ways for it to all go wrong. However
generally WE don't get to write the kernel and driver
code here - someone else, who thinks paragraph-length
names sound SO COOL, are who writes it.
On 2025-05-01, c186282 <c186282@nnada.net> wrote:
On 4/30/25 6:00 AM, Borax Man wrote:
On 2025-04-29, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
On Tue, 29 Apr 2025 14:18:48 -0000 (UTC), Borax Man wrote:Well, you get to choose the filesystem you use. JFS2 if I recall could
As for your file example though, you do demonstrate why one may choose >>>>> upper vs lower case, Windows does allow that. But should they be
*seperate* files?
It should be your choice.
be case insensitive, but i would play havoc with the OS if you used it
in the wron place. In Windows, can you make it case sensitive?
However, I agree with your comment about unicode. Treating upper and >>>>> lower case letters as the same, leads to complicated rules, which may >>>>> vary from system to system, and cause chaos.
Unicode seems to have come up with some standard set of “default” rules
that are independent of any particular localization setting.
These would need to be in a standard, one that filesystems can
implement. But then filesystems would have to implement the same
standard, otherwise, again issues arise. Can't see this being workable
for end users.
So, in essence, the development of case-sensitive
systems ruined it for case-insensitive :-)
Same now for space-tolerant file names.
Case sensitivity does cause problems here and there, and it was
initially confusing.
But spaces in filenames cause me *far more* headaches. They are the
greater evil.
On Thu, 1 May 2025 13:42:36 -0000 (UTC), Borax Man wrote:
But spaces in filenames cause me *far more* headaches. They are the
greater evil.
The real evil was the mishmash of DOS and Windows that wound up with
'Program Files' becoming 'progra~1'.
On 01/05/2025 14:42, Borax Man wrote:
On 2025-05-01, c186282 <c186282@nnada.net> wrote:
On 4/30/25 6:00 AM, Borax Man wrote:
On 2025-04-29, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
On Tue, 29 Apr 2025 14:18:48 -0000 (UTC), Borax Man wrote:Well, you get to choose the filesystem you use. JFS2 if I recall could >>>> be case insensitive, but i would play havoc with the OS if you used it >>>> in the wron place. In Windows, can you make it case sensitive?
As for your file example though, you do demonstrate why one may choose >>>>>> upper vs lower case, Windows does allow that. But should they be
*seperate* files?
It should be your choice.
However, I agree with your comment about unicode. Treating upper and >>>>>> lower case letters as the same, leads to complicated rules, which may >>>>>> vary from system to system, and cause chaos.
Unicode seems to have come up with some standard set of “default” rules
that are independent of any particular localization setting.
These would need to be in a standard, one that filesystems can
implement. But then filesystems would have to implement the same
standard, otherwise, again issues arise. Can't see this being workable >>>> for end users.
So, in essence, the development of case-sensitive
systems ruined it for case-insensitive :-)
Same now for space-tolerant file names.
Case sensitivity does cause problems here and there, and it was
initially confusing.
But spaces in filenames cause me *far more* headaches. They are the
greater evil.
I LOVE spaces in filenames.
I guess if you use the command line a lot and parse file arguments using spaces, its a bit irritating.
But if you uses a GUI its no issue at all
I LOVE spaces in filenames.
I guess if you use the command line a lot and parse file arguments
using spaces, its a bit irritating.
But if you uses a GUI its no issue at all
The Natural Philosopher <tnp@invalid.invalid> writes:
I LOVE spaces in filenames.
I guess if you use the command line a lot and parse file arguments
using spaces, its a bit irritating.
But if you uses a GUI its no issue at all
Quite. It’s only shell that has a problem with spaces, so it seems like it’s not the spaces that are the problem, but the language.
I LOVE spaces in filenames.
I guess if you use the command line a lot and parse file arguments using spaces, its a bit irritating.
But if you uses a GUI its no issue at all
On Thu, 1 May 2025 22:07:19 -0000 (UTC), Lawrence D'Oliveiro wrote:
I do regexps all the time. I appreciate the fact that the default
setting for searches in Emacs (for both plain strings and regexps) is to
be case- insensitive, unless the pattern/string includes a capital
letter, in which case it becomes case-sensitive.
My default in Vim is to ignore case. ':se noic' (set no ignorecase) is
easy enough if I'm looking for a specific camel case item. ':se ic' puts
it back to insensitive. Having it triggered by a capital letter might be
nice but I've got a feeling sooner or later there would be an edge case.
On 2025-05-02, The Natural Philosopher <tnp@invalid.invalid> wrote:
I LOVE spaces in filenames.
I guess if you use the command line a lot and parse file arguments using
spaces, its a bit irritating.
But if you uses a GUI its no issue at all
Yes, I'm a command line kind of guy, and spaces are a bit of a PITA.
Just have to remember to quote, but when you use shell expansions or globbing, and then things get a bit trickier.
Yes, I'm a command line kind of guy, and spaces are a bit of a PITA.
Just have to remember to quote, but when you use shell expansions or globbing, and then things get a bit trickier.
On 2 May 2025 17:18:10 +1000, Computer Nerd Kev wrote:
For one thing it makes shell scripting complicated ...
This may be true of a straight POSIX shell, but there are techniques for coping with arbitrary filenames in Bash, just for example.
... and for another this is just really confusing ...
Just tried it:
ldo@theon:try> touch file1 file2$'\n'file3 file4
ldo@theon:try> ls -1
file1
'file2'$'\n''file3'
file4
ldo@theon:try> ls -1 --quoting-style=literal
file1
file2?file3
file4
Wasn't so bad, was it?
On Fri, 02 May 2025 07:10:29 GMT, Charlie Gibbs wrote:
On 2025-05-02, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
On Fri, 02 May 2025 00:15:50 GMT, Charlie Gibbs wrote:
We encountered a bug in the sort routine used by Micro Focus
COBOL. By default it created ridiculously small work files, so
when we tried sorting a very large file, the numeric portion of
work file names (of the form "worknnn") ran up to 999, wrapped
around, and carried into the alphanumeric portion - which ran all
the way up the ASCII chart, wrapped around to \0, and worked up
from there. After the inevitable crash, we had 12,000 work files
to get rid of, which had just about any character value in their
names. What a mess.
Weren’t they all in a temporary work directory?
Unfortunately, no.
Ah. But they did all begin with “WORK”, did they not? Didn’t “DELETE WORK???” or “DELETE WORK*”, ahem, work?
Le 02-05-2025, Borax Man <rotflol2@hotmail.com> a écrit :
On 2025-05-02, The Natural Philosopher <tnp@invalid.invalid> wrote:
I LOVE spaces in filenames.
I guess if you use the command line a lot and parse file arguments using >>> spaces, its a bit irritating.
But if you uses a GUI its no issue at all
Yes, I'm a command line kind of guy, and spaces are a bit of a PITA.
Just have to remember to quote, but when you use shell expansions or
globbing, and then things get a bit trickier.
I don't see the difficulty with the spaces in my terminal. My bash
manages very well the spaces when I'm using my TAB on files which have
some spaces in their names.
On Fri, 2 May 2025 14:54:56 -0000 (UTC), Borax Man wrote:
Yes, I'm a command line kind of guy, and spaces are a bit of a PITA.
Just have to remember to quote, but when you use shell expansions or
globbing, and then things get a bit trickier.
I'm not crazy about uppercase directories either. Desktop, Documents, Downloads and so forth feels like something that snuck* in from Windows.
* 'sneaked' for the Brits and others who need regularity in their lives.
Well now it's gone from the bad situation of confusing filename output
to the worse situation of completely different output from different
common command-line programs ...
I LOVE spaces in filenames.
Generally I can deal with it, but I still have trouble with rsync.
There's something to do with single quotes vs. double quotes that I
haven't quite wrapped my head around yet.
It’s only shell that has a problem with spaces, so it seems like
it’s not the spaces that are the problem, but the language.
On 2025-05-02, rbowman <bowman@montana.com> wrote:
On Fri, 2 May 2025 14:54:56 -0000 (UTC), Borax Man wrote:
Yes, I'm a command line kind of guy, and spaces are a bit of a PITA.
Just have to remember to quote, but when you use shell expansions or
globbing, and then things get a bit trickier.
I'm not crazy about uppercase directories either. Desktop, Documents,
Downloads and so forth feels like something that snuck* in from
Windows.
* 'sneaked' for the Brits and others who need regularity in their
lives.
I do admit, I tend to do this a bit, as I like to capitalise nouns (I'm
a capitalist, you see). But somtimes I think to myself, "why are you
doing this?"
It probably wasn't "work", I forget now. All I remember is that it was
done in such a way as to make clean-up very ugly. Hopefully Micro Focus cleaned up their act not long afterwards.
On 2 May 2025 17:18:10 +1000, Computer Nerd Kev wrote:
For one thing it makes shell scripting complicated ...
This may be true of a straight POSIX shell, but there are techniques for coping with arbitrary filenames in Bash, just for example.
... and for another this is just really confusing ...
Just tried it:
ldo@theon:try> touch file1 file2$'\n'file3 file4
ldo@theon:try> ls -1
file1
'file2'$'\n''file3'
file4
ldo@theon:try> ls -1 --quoting-style=literal
file1
file2?file3
file4
ldo@theon:try> rm file*
ldo@theon:try> cd ..
ldo@theon:hack> rmdir try
Wasn’t so bad, was it?
Generally I can deal with it, but I still have trouble with rsync.
There's something to do with single quotes vs. double quotes that I
haven't quite wrapped my head around yet.
On 3 May 2025 08:58:14 +1000, Computer Nerd Kev wrote:
Well now it's gone from the bad situation of confusing filename output
to the worse situation of completely different output from different
common command-line programs ...
No, you just get different output options available in the same program, namely GNU ls.
On Fri, 02 May 2025 22:29:35 GMT, Charlie Gibbs wrote:
Generally I can deal with it, but I still have trouble with rsync.
There's something to do with single quotes vs. double quotes that I
haven't quite wrapped my head around yet.
They are a general PITA. I really like those situations when you can have single quotes within a double quoted string or double quotes within a
single quoted string and languages that play fast and loose like Python or JavaScript where you can use either -- most of the time.
Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
On 3 May 2025 08:58:14 +1000, Computer Nerd Kev wrote:
Well now it's gone from the bad situation of confusing filename output
to the worse situation of completely different output from different
common command-line programs ...
No, you just get different output options available in the same program,
namely GNU ls.
And completely unstandardised between programs, even the defaults of
the GNU versions of ls and find. So you never know how newlines in
filenames will appear in any one program's output. The only good
solution is if they're never there in the first place, but
unfortunately they are allowed to be.
Seems [-print0] disables converting newlines to '?' and ends results
with null instead.
This describes how that's not always a solution.
On 5/2/25 11:18 PM, rbowman wrote:
On Fri, 02 May 2025 22:29:35 GMT, Charlie Gibbs wrote:
Generally I can deal with it, but I still have trouble with rsync.
There's something to do with single quotes vs. double quotes that I
haven't quite wrapped my head around yet.
They are a general PITA. I really like those situations when you can
have single quotes within a double quoted string or double quotes
within a single quoted string and languages that play fast and loose
like Python or JavaScript where you can use either -- most of the time.
NOTE that what you're advocating is More And More COMPLICATED ...
work-arounds for work-arounds.
The Natural Philosopher <tnp@invalid.invalid> writes:
I LOVE spaces in filenames.
I guess if you use the command line a lot and parse file arguments
using spaces, its a bit irritating.
But if you uses a GUI its no issue at all
Quite. It’s only shell that has a problem with spaces, so it seems like it’s not the spaces that are the problem, but the language.
Le 02-05-2025, Borax Man <rotflol2@hotmail.com> a écrit :
On 2025-05-02, The Natural Philosopher <tnp@invalid.invalid> wrote:
I LOVE spaces in filenames.
I guess if you use the command line a lot and parse file arguments using >>> spaces, its a bit irritating.
But if you uses a GUI its no issue at all
Yes, I'm a command line kind of guy, and spaces are a bit of a PITA.
Just have to remember to quote, but when you use shell expansions or
globbing, and then things get a bit trickier.
I don't see the difficulty with the spaces in my terminal. My bash
manages very well the spaces when I'm using my TAB on files which have
some spaces in their names.
On 2025-05-02, The Natural Philosopher <tnp@invalid.invalid> wrote:
On 01/05/2025 14:42, Borax Man wrote:
On 2025-05-01, c186282 <c186282@nnada.net> wrote:
On 4/30/25 6:00 AM, Borax Man wrote:
On 2025-04-29, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
On Tue, 29 Apr 2025 14:18:48 -0000 (UTC), Borax Man wrote:Well, you get to choose the filesystem you use. JFS2 if I recall could >>>>> be case insensitive, but i would play havoc with the OS if you used it >>>>> in the wron place. In Windows, can you make it case sensitive?
As for your file example though, you do demonstrate why one may choose >>>>>>> upper vs lower case, Windows does allow that. But should they be >>>>>>> *seperate* files?
It should be your choice.
However, I agree with your comment about unicode. Treating upper and >>>>>>> lower case letters as the same, leads to complicated rules, which may >>>>>>> vary from system to system, and cause chaos.
Unicode seems to have come up with some standard set of “default” rules
that are independent of any particular localization setting.
These would need to be in a standard, one that filesystems can
implement. But then filesystems would have to implement the same
standard, otherwise, again issues arise. Can't see this being workable >>>>> for end users.
So, in essence, the development of case-sensitive
systems ruined it for case-insensitive :-)
Same now for space-tolerant file names.
Case sensitivity does cause problems here and there, and it was
initially confusing.
But spaces in filenames cause me *far more* headaches. They are the
greater evil.
I LOVE spaces in filenames.
I guess if you use the command line a lot and parse file arguments using
spaces, its a bit irritating.
But if you uses a GUI its no issue at all
Yes, I'm a command line kind of guy, and spaces are a bit of a PITA.
Just have to remember to quote, but when you use shell expansions or globbing, and then things get a bit trickier.
On 2025-05-02, rbowman <bowman@montana.com> wrote:
On Fri, 2 May 2025 14:54:56 -0000 (UTC), Borax Man wrote:
Yes, I'm a command line kind of guy, and spaces are a bit of a PITA.
Just have to remember to quote, but when you use shell expansions or
globbing, and then things get a bit trickier.
I'm not crazy about uppercase directories either. Desktop, Documents,
Downloads and so forth feels like something that snuck* in from Windows.
* 'sneaked' for the Brits and others who need regularity in their lives.
I do admit, I tend to do this a bit, as I like to capitalise nouns (I'm
a capitalist, you see). But somtimes I think to myself, "why are you doing this?"
On 01/05/2025 14:42, Borax Man wrote:
On 2025-05-01, c186282 <c186282@nnada.net> wrote:
On 4/30/25 6:00 AM, Borax Man wrote:
On 2025-04-29, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
On Tue, 29 Apr 2025 14:18:48 -0000 (UTC), Borax Man wrote:Well, you get to choose the filesystem you use. JFS2 if I recall could >>>> be case insensitive, but i would play havoc with the OS if you used it >>>> in the wron place. In Windows, can you make it case sensitive?
As for your file example though, you do demonstrate why one may
choose
upper vs lower case, Windows does allow that. But should they be >>>>>> *seperate* files?
It should be your choice.
However, I agree with your comment about unicode. Treating upper and >>>>>> lower case letters as the same, leads to complicated rules, which may >>>>>> vary from system to system, and cause chaos.
Unicode seems to have come up with some standard set of “default” >>>>> rules
that are independent of any particular localization setting.
These would need to be in a standard, one that filesystems can
implement. But then filesystems would have to implement the same
standard, otherwise, again issues arise. Can't see this being workable >>>> for end users.
So, in essence, the development of case-sensitive
systems ruined it for case-insensitive :-)
Same now for space-tolerant file names.
Case sensitivity does cause problems here and there, and it was
initially confusing.
But spaces in filenames cause me *far more* headaches. They are the
greater evil.
I LOVE spaces in filenames.
I guess if you use the command line a lot and parse file arguments using spaces, its a bit irritating.
But if you uses a GUI its no issue at all
On 2025-05-02 11:53, The Natural Philosopher wrote:
On 01/05/2025 14:42, Borax Man wrote:
On 2025-05-01, c186282 <c186282@nnada.net> wrote:
On 4/30/25 6:00 AM, Borax Man wrote:
On 2025-04-29, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
On Tue, 29 Apr 2025 14:18:48 -0000 (UTC), Borax Man wrote:Well, you get to choose the filesystem you use. JFS2 if I recall
As for your file example though, you do demonstrate why one may
choose
upper vs lower case, Windows does allow that. But should they be >>>>>>> *seperate* files?
It should be your choice.
could
be case insensitive, but i would play havoc with the OS if you used it >>>>> in the wron place. In Windows, can you make it case sensitive?
However, I agree with your comment about unicode. Treating upper >>>>>>> and
lower case letters as the same, leads to complicated rules, which >>>>>>> may
vary from system to system, and cause chaos.
Unicode seems to have come up with some standard set of “default” >>>>>> rules
that are independent of any particular localization setting.
These would need to be in a standard, one that filesystems can
implement. But then filesystems would have to implement the same
standard, otherwise, again issues arise. Can't see this being
workable
for end users.
So, in essence, the development of case-sensitive
systems ruined it for case-insensitive :-)
Same now for space-tolerant file names.
Case sensitivity does cause problems here and there, and it was
initially confusing.
But spaces in filenames cause me *far more* headaches. They are the
greater evil.
I LOVE spaces in filenames.
I guess if you use the command line a lot and parse file arguments
using spaces, its a bit irritating.
But if you uses a GUI its no issue at all
Same here.
And yes, I do scripts and it complicates them. Still... it makes
filenames more readable. Book names, movie names, document names... I
also like the colon ":" in filenames. It runs havoc with Windows users, though :-)
"CAT" is an acronym for "Computed Axial Tomography."
"cat" is the useless animal that gives comfort to sterile women.
I think It's usually CT these days. CAT is somewhat of an archaic usage.
As for cats - I'm neither sterile nor female and I like cats.
On Mon, 28 Apr 2025 12:31:06 -0700, John Ames wrote:
On Mon, 28 Apr 2025 18:56:18 +0000
Farley Flud <ff@linux.rocks> wrote:
What about the files:
cat_scan_links.html
CAT_scan_links.html
What *about* them? Your first example made more of a case that the
problem can be complex;* this one is eminently straightforward.
* (Although it still does not seem prohibitively so.)
I'll give you a hint.
"CAT" is an acronym for "Computed Axial Tomography."
"cat" is the useless animal that gives comfort to sterile women.
On 02/05/2025 17:41, Richard Kettlewell wrote:
The Natural Philosopher <tnp@invalid.invalid> writes:
I LOVE spaces in filenames.Quite. It’s only shell that has a problem with spaces, so it seems
I guess if you use the command line a lot and parse file arguments
using spaces, its a bit irritating.
But if you uses a GUI its no issue at all
like it’s not the spaces that are the problem, but the language.
To be fair its built in to the C language as well in the sense that
that's how argc and argv[] are created.
Farley Flud <ff@linux.rocks> writes:
On Mon, 28 Apr 2025 12:31:06 -0700, John Ames wrote:
On Mon, 28 Apr 2025 18:56:18 +0000
Farley Flud <ff@linux.rocks> wrote:
What about the files:
cat_scan_links.html
CAT_scan_links.html
What *about* them? Your first example made more of a case that the
problem can be complex;* this one is eminently straightforward.
* (Although it still does not seem prohibitively so.)
I'll give you a hint.
"CAT" is an acronym for "Computed Axial Tomography."
"cat" is the useless animal that gives comfort to sterile women.
I think It's usually CT these days. CAT is somewhat of an archaic usage.
As for cats - I'm neither sterile nor female and I like cats.
The Natural Philosopher <tnp@invalid.invalid> writes:
On 02/05/2025 17:41, Richard Kettlewell wrote:
The Natural Philosopher <tnp@invalid.invalid> writes:
I LOVE spaces in filenames.Quite. It’s only shell that has a problem with spaces, so it seems
I guess if you use the command line a lot and parse file arguments
using spaces, its a bit irritating.
But if you uses a GUI its no issue at all
like it’s not the spaces that are the problem, but the language.
To be fair its built in to the C language as well in the sense that
that's how argc and argv[] are created.
Not really. As far as C is concerned, it’s just an array of strings; how it’s created is someone else’s problem. Who the ‘someone else’ is depends on the platform...
In Unix, the space-based splitting is part of the shell.
What you pass
to execve() is an array of strings, so if you can keep the shell out of
the picture, you get to specify exactly what appear in the child
program’s argv without any extra parsing or formatting being involved.
In Windows, the splitting is instead part of the language runtime, since CreateProcess() takes a single command line string. The child process’s runtime does the splitting (according to rules complicated enough to
result in vulnerabilities) - or not, if WinMain() is used.
On Fri, 02 May 2025 22:29:35 GMT, Charlie Gibbs wrote:
Generally I can deal with it, but I still have trouble with rsync.
There's something to do with single quotes vs. double quotes that I
haven't quite wrapped my head around yet.
This is an issue with SSH (and possibly RSH before that as well). There
needs to be an extra level of quoting when executing a command remotely by directly specifying it on the SSH command line, because you have a shell
at the remote end, as well as the local end, being triggered by shell- special characters.
On 2025-05-03 01:59, Borax Man wrote:
On 2025-05-02, rbowman <bowman@montana.com> wrote:
On Fri, 2 May 2025 14:54:56 -0000 (UTC), Borax Man wrote:
Yes, I'm a command line kind of guy, and spaces are a bit of a PITA.
Just have to remember to quote, but when you use shell expansions or
globbing, and then things get a bit trickier.
I'm not crazy about uppercase directories either. Desktop, Documents,
Downloads and so forth feels like something that snuck* in from Windows. >>>
* 'sneaked' for the Brits and others who need regularity in their lives.
I do admit, I tend to do this a bit, as I like to capitalise nouns (I'm
a capitalist, you see). But somtimes I think to myself, "why are you doing >> this?"
They sort to the top of the list.
On Fri, 2 May 2025 23:59:01 -0000 (UTC), Borax Man wrote:
On 2025-05-02, rbowman <bowman@montana.com> wrote:
On Fri, 2 May 2025 14:54:56 -0000 (UTC), Borax Man wrote:
Yes, I'm a command line kind of guy, and spaces are a bit of a PITA.
Just have to remember to quote, but when you use shell expansions or
globbing, and then things get a bit trickier.
I'm not crazy about uppercase directories either. Desktop, Documents,
Downloads and so forth feels like something that snuck* in from
Windows.
* 'sneaked' for the Brits and others who need regularity in their
lives.
I do admit, I tend to do this a bit, as I like to capitalise nouns (I'm
a capitalist, you see). But somtimes I think to myself, "why are you
doing this?"
My German is very rusty but I find it much more logical than English. If
it's a noun, capitalize it. It is particularly helpful in these divisive times when you can get into a flame war over a capital.
On 03/05/2025 15:59, Richard Kettlewell wrote:
In Unix, the space-based splitting is part of the shell.
No, its part of the runtime of the C language
On 2025-05-03, Carlos E.R. <robin_listas@es.invalid> wrote:
On 2025-05-03 01:59, Borax Man wrote:
On 2025-05-02, rbowman <bowman@montana.com> wrote:
On Fri, 2 May 2025 14:54:56 -0000 (UTC), Borax Man wrote:I do admit, I tend to do this a bit, as I like to capitalise nouns (I'm
Yes, I'm a command line kind of guy, and spaces are a bit of a PITA. >>>>> Just have to remember to quote, but when you use shell expansions or >>>>> globbing, and then things get a bit trickier.
I'm not crazy about uppercase directories either. Desktop, Documents,
Downloads and so forth feels like something that snuck* in from Windows. >>>>
* 'sneaked' for the Brits and others who need regularity in their lives. >>>
a capitalist, you see). But somtimes I think to myself, "why are you doing >>> this?"
They sort to the top of the list.
Some cow orkers accomplish that by prefixing the name with an
exclamation mark. This sets my teeth on edge. If you're trying
to section off a group of names, why not use a subdirectory?
The other thing I like about German is that the spelling and
pronunciation of "ie" vs "ei" is 100% consistent, unlike the mish-mosh
you find in English.
But making it an 'array of strings' is *already* parsing and formatting
it!
I also like the colon ":" in filenames. It runs havoc with Windows
users, though :-)
Some characters cause havoc with some programs, too.
I think It's usually CT these days. CAT is somewhat of an archaic usage.
On 2025-05-03, rbowman <bowman@montana.com> wrote:
On Fri, 2 May 2025 23:59:01 -0000 (UTC), Borax Man wrote:
On 2025-05-02, rbowman <bowman@montana.com> wrote:
On Fri, 2 May 2025 14:54:56 -0000 (UTC), Borax Man wrote:
Yes, I'm a command line kind of guy, and spaces are a bit of a PITA. >>>>> Just have to remember to quote, but when you use shell expansions or >>>>> globbing, and then things get a bit trickier.
I'm not crazy about uppercase directories either. Desktop, Documents,
Downloads and so forth feels like something that snuck* in from
Windows.
* 'sneaked' for the Brits and others who need regularity in their
lives.
I do admit, I tend to do this a bit, as I like to capitalise nouns (I'm
a capitalist, you see). But somtimes I think to myself, "why are you
doing this?"
My German is very rusty but I find it much more logical than English. If
it's a noun, capitalize it. It is particularly helpful in these divisive
times when you can get into a flame war over a capital.
The other thing I like about German is that the spelling and
pronunciation of "ie" vs "ei" is 100% consistent, unlike the
mish-mosh you find in English.
The capitalization quirk that irritates me is what I call Cute Caps,
where people will Capitalize random Words because it looks Cute and
they don't know How to Emphasize Properly.
[Capitalized names] sort to the top of the list.
Some cow orkers accomplish that by prefixing the name with an
exclamation mark. This sets my teeth on edge.
The other thing I like about German is that the spelling and
pronunciation of "ie" vs "ei" is 100% consistent, unlike the
mish-mosh you find in English.
The capitalization quirk that irritates me is what I call Cute Caps,
where people will Capitalize random Words because it looks Cute and
they don't know How to Emphasize Properly.
Primitive things obsoleted by a GUI :-)
A couple decades ago, the "French Everything" crusade in that country
demanded French-only terms for stuff.
The native French for 'satellite' was, well, like an entire sentence
On Sat, 3 May 2025 11:33:52 +0100, The Natural Philosopher wrote:
Primitive things obsoleted by a GUI :-)
You didn’t get the memo from Microsoft, that command lines are officially cool again?
On Sat, 3 May 2025 22:06:57 -0400, c186282 wrote:
A couple decades ago, the "French Everything" crusade in that country
demanded French-only terms for stuff.
The native French for 'satellite' was, well, like an entire sentence
German isn't shy about using loan words but they like to stick them
together.
https://www.youtube.com/watch?v=J5BcAbMdF18
fwiw, John Kay was born in East Prussia which is now Kaliningrad Oblast so mocking German comes naturally. Russia has the same problem as Germany
did after WWI and the Danzig Corridor; the oblast not connected to the
rest of Russia.
Vlad plans to fix that. Just a couple of little countries in his way
.......
On 5/3/25 10:29 PM, Lawrence D'Oliveiro wrote:
On Sat, 3 May 2025 11:33:52 +0100, The Natural Philosopher wrote:
Primitive things obsoleted by a GUI :-)
You didn’t get the memo from Microsoft, that command lines are
officially cool again?
STILL do most of my stuff over SSH/nano ... VNC can be too touchy,
too often just grey screens.
Command-line always works.
On Sat, 3 May 2025 22:43:55 -0400, c186282 wrote:
Vlad plans to fix that. Just a couple of little countries in his way
.......
So far, so good but it must be in the back of his mind. Russia's only ice free Baltic port is in that oblast so that's where the fleet lives.
That was the real start of WWII. Germany wanted to build a highway to East Prussia. No entrances, and no exits, just a way to get there on land. The Poles believed Britain had their backs and were uppity about it. The Brits weren't in a position to have anybody's back at the time. I wonder if Zelensky reads much history?
Of course Baltic ports aren't that great nor are the Crimean ports.
The Natural Philosopher <tnp@invalid.invalid> writes:
On 03/05/2025 15:59, Richard Kettlewell wrote:
In Unix, the space-based splitting is part of the shell.
No, its part of the runtime of the C language
It really isn’t. You can trace it through the implementation of execve
and the Glibc startup, if you want.
On 5/3/25 10:33 PM, rbowman wrote:
On Sat, 3 May 2025 22:06:57 -0400, c186282 wrote:
A couple decades ago, the "French Everything" crusade in thatGerman isn't shy about using loan words but they like to stick them
country
demanded French-only terms for stuff.
The native French for 'satellite' was, well, like an entire sentence >>
together.
https://www.youtube.com/watch?v=J5BcAbMdF18
Heh ... yea ... I noticed the German fetish for
creating single LONG LONG words :-)
fwiw, John Kay was born in East Prussia which is now Kaliningrad
Oblast so
mocking German comes naturally. Russia has the same problem as Germany
did after WWI and the Danzig Corridor; the oblast not connected to the
rest of Russia.
Vlad plans to fix that. Just a couple of little
countries in his way .......
In a GUI, are you using proportional fonts in your
file browser ? If so, can you spot ONE space -vs-
TWO spaces ???
On Sat, 3 May 2025 11:33:52 +0100, The Natural Philosopher wrote:
Primitive things obsoleted by a GUI :-)
You didn’t get the memo from Microsoft, that command lines are officially cool again?
I mean you can trace the transmission of the command line from parent to child process through the startup. There’s no splitting in there, it’s
an array of strings from top to bottom.
The splitting on spaces (and
handling of quotes etc) happens in the shell.
On 03/05/2025 21:08, Richard Kettlewell wrote:
The Natural Philosopher <tnp@invalid.invalid> writes:And those are not part of the C language?
On 03/05/2025 15:59, Richard Kettlewell wrote:It really isn’t. You can trace it through the implementation of
In Unix, the space-based splitting is part of the shell.
No, its part of the runtime of the C language
execve and the Glibc startup, if you want.
On 04/05/2025 14:41, Richard Kettlewell wrote:
I mean you can trace the transmission of the command line from parent
to child process through the startup. There’s no splitting in there,
it’s an array of strings from top to bottom.
But the command line is not an array of strings... any more than this
line of text is. That's what I don't understand. It's a single string
The splitting on spaces (and handling of quotes etc) happens in the
shell.
An array by definition is already split. On what basis is it split?
The Natural Philosopher <tnp@invalid.invalid> writes:
On 04/05/2025 14:41, Richard Kettlewell wrote:
I mean you can trace the transmission of the command line from parent
to child process through the startup. There’s no splitting in there,
it’s an array of strings from top to bottom.
But the command line is not an array of strings... any more than this
line of text is. That's what I don't understand. It's a single string
The command line _in the shell_ is a single string, that you have typed
in:
mv ugly_filename.txt 'beautiful filename.txt'
Once the shell reads it, that still looks like a single string:
And Germans end up thinking in nouns, making their 'Weltauunschung' very concrete.
On 2025-05-04 04:29, Lawrence D'Oliveiro wrote:
On Sat, 3 May 2025 11:33:52 +0100, The Natural Philosopher wrote:
Primitive things obsoleted by a GUI :-)
You didn’t get the memo from Microsoft, that command lines are
officially cool again?
Can you ssh to Windows and get a command shell? I don't know, I'm
wondering.
On Sun, 4 May 2025 13:53:49 +0200, Carlos E.R. wrote:
On 2025-05-04 04:29, Lawrence D'Oliveiro wrote:
On Sat, 3 May 2025 11:33:52 +0100, The Natural Philosopher wrote:
Primitive things obsoleted by a GUI :-)
You didn’t get the memo from Microsoft, that command lines are
officially cool again?
Can you ssh to Windows and get a command shell? I don't know, I'm
wondering.
https://www.putty.org/
I frequently use PuTTY to ssh into Linux boxes on the network but use RDP
to get to the Windows boxes. The Bitvise SSH Server sounds like it would work.
But you said
" it’s an array of strings from top to bottom."
Not "is a single string, that you have typed in"
The Natural Philosopher <tnp@invalid.invalid> writes:
No, its part of the runtime of the C language
It really isn’t. You can trace it through the implementation of execve
and the Glibc startup, if you want.
On Sat, 3 May 2025 22:41:10 -0400, c186282 wrote:
On 5/3/25 10:29 PM, Lawrence D'Oliveiro wrote:
On Sat, 3 May 2025 11:33:52 +0100, The Natural Philosopher wrote:
Primitive things obsoleted by a GUI :-)
You didn’t get the memo from Microsoft, that command lines are
officially cool again?
STILL do most of my stuff over SSH/nano ... VNC can be too touchy,
too often just grey screens.
Command-line always works.
I was skeptical about using VNC to one of the Raspberry Pis but it works okay. All I do is open Terminal anyway so there's not a lot going on. It
is easier to use the config gui to turn on SPI and I2C as needed though.
I know putty, but what I want is to ssh into Windows and get an actual
shell where I can run Windows commands. Out of the box, obviously, so
extra software is not an option.
On Sun, 4 May 2025 12:17:14 +0100, The Natural Philosopher wrote:
And Germans end up thinking in nouns, making their 'Weltauunschung' very
concrete.
You prefer Wolkenkuckucksheim?
On Sun, 4 May 2025 22:40:43 +0200, Carlos E.R. wrote:
I know putty, but what I want is to ssh into Windows and get an actual
shell where I can run Windows commands. Out of the box, obviously, so
extra software is not an option.
Depends on what you mean by extra software. On Windows Server 2025 the OpenSSH Server is included. On Windows 11
1. Open Settings
2. Search for optional features
3. In 'add optional feature' hit 'View Features'
4. Search for OpenSSH Server
5. Check the box and install it
6. open services.msc
7. sshd will be set to manual. Set to Automatic and start it.
Maybe not necessary:
8. In %windir%\system32\OpenSSH copy sshd_config_default to sshd_config
9. Uncomment PasswordAuthentication
10. Check to see if there is an inbound rule for port 22
11. Restart sshd
You can also start sshd.exe from the OpenSSH directory. I had a timeout connecting, tried manual starting, and got a disconnect after entering my password. I modified the config, restarted the service and
ssh rbowman@192.168.1.14
rbowman@192.168.1.14's password:
gets me
rbowman@LAPTOP-4JQQ0FSD C:\Users\rbowman>
and I can happily navigate around.
I have windows home, some times profesional. w10, I don't remember if I
have w11 somewhere.
On Mon, 5 May 2025 13:12:48 +0200, Carlos E.R. wrote:
I have windows home, some times profesional. w10, I don't remember if I
have w11 somewhere.
https://docs.ssw.splashtop.com/docs/installing-and-enabling-openssh-on- windows
The procedure is the same, assuming your Win 10 box is anywhere near up to date.
Computer Nerd Kev <not@telling.you.invalid> wrote:
I question the wisdom of Torvalds on this topic since he allowed
ext filesystems to have an even greater evil than either of those:
newlines in file names! Imagine if the average joe were exposed
to that capability - we'd have multi-paragraph file names to deal
with all over the place.
Torvalds did not "allow newlines". Unix filesystems, long before Linux
ever existed, have only disallowed two characters in filenames:
ASCII null (because C strings are ASCII null terminated)
The forward slash (/) (because forward slash is used as the directory separator).
Torvalds was simply following standard Unix protocol (in order to be compatible with Unix standards) for what was "allowed" to be in a
filename.
rbowman <bowman@montana.com> wrote:
On Thu, 1 May 2025 13:42:36 -0000 (UTC), Borax Man wrote:
But spaces in filenames cause me *far more* headaches. They are the
greater evil.
The real evil was the mishmash of DOS and Windows that wound up with
'Program Files' becoming 'progra~1'.
I question the wisdom of Torvalds on this topic since he allowed
ext filesystems to have an even greater evil than either of those:
newlines in file names! Imagine if the average joe were exposed
to that capability - we'd have multi-paragraph file names to deal
with all over the place.
Rich <rich@example.invalid> wrote:
Computer Nerd Kev <not@telling.you.invalid> wrote:
I question the wisdom of Torvalds on this topic since he allowed
ext filesystems to have an even greater evil than either of those:
newlines in file names! Imagine if the average joe were exposed
to that capability - we'd have multi-paragraph file names to deal
with all over the place.
Torvalds did not "allow newlines". Unix filesystems, long before Linux
ever existed, have only disallowed two characters in filenames:
ASCII null (because C strings are ASCII null terminated)
The forward slash (/) (because forward slash is used as the directory
separator).
Torvalds was simply following standard Unix protocol (in order to be
compatible with Unix standards) for what was "allowed" to be in a
filename.
Perhaps, but since he wasn't using existing UNIX filesystems and
using a custom one instead, it seems to me like he had a choice.
After all you can still use FAT or NTFS on Linux even though they
have more disallowed filename characters.
It could have been the same with ext* forbidding newlines (also tmpfs
etc.). Then you'd only have to worry about handling newlines in the
rare case of reading from some non-Linux filesystems like UFS.
Perhaps, but since he wasn't using existing UNIX filesystems and using a custom one instead, it seems to me like he had a choice.
After all you can still use FAT or NTFS on Linux even though they have
more disallowed filename characters.
Perhaps, but since he wasn't using existing UNIX filesystems and using a custom one instead, it seems to me like he had a choice. After all you
can still use FAT or NTFS on Linux even though they have more disallowed filename characters. It could have been the same with ext* forbidding newlines (also tmpfs etc.). Then you'd only have to worry about handling newlines in the rare case of reading from some non-Linux filesystems
like UFS.
On Mon, 5 May 2025 13:12:48 +0200, Carlos E.R. wrote:
I have windows home, some times profesional. w10, I don't remember if I
have w11 somewhere.
https://docs.ssw.splashtop.com/docs/installing-and-enabling-openssh-on- windows
The procedure is the same, assuming your Win 10 box is anywhere near up to date.
I don't have any Win boxes - Linux or BSD. Same for decades now.
DID kinda like Win2k ... last "simple" incarnation.
But ... MAY have a VM of it, maybe, for fun.
Rich <rich@example.invalid> wrote:
Torvalds did not "allow newlines". Unix filesystems, long before
Linux ever existed, have only disallowed two characters in filenames:
ASCII null (because C strings are ASCII null terminated)
The forward slash (/) (because forward slash is used as the directory
separator).
Torvalds was simply following standard Unix protocol (in order to be
compatible with Unix standards) for what was "allowed" to be in a
filename.
Perhaps, but since he wasn't using existing UNIX filesystems and
using a custom one instead, it seems to me like he had a choice.
After all you can still use FAT or NTFS on Linux even though they
have more disallowed filename characters. It could have been the
same with ext* forbidding newlines (also tmpfs etc.). Then you'd
only have to worry about handling newlines in the rare case of
reading from some non-Linux filesystems like UFS.
I suspect the filename restrictions would make FAT as a rootfs
challenging.
Richard Kettlewell wrote:
I suspect the filename restrictions would make FAT as a rootfs
challenging.
vfat does show up as the format for /boot/efi or a similar location
for UEFI systems. It's small, just enough to satisfy the UEFI and get
things going.
I don't have any Win boxes - Linux or BSD. Same
for decades now.
DID kinda like Win2k ... last "simple" incarnation.
But ... MAY have a VM of it, maybe, for fun.
I suspect the filename restrictions would make FAT as a rootfs
challenging.
On 04/05/2025 14:41, Richard Kettlewell wrote:
I mean you can trace the transmission of the command line from parent to
child process through the startup. There’s no splitting in there, it’s >> an array of strings from top to bottom.
But the command line is not an array of strings... any more than this
line of text is. That's what I don't understand. It's a single string
The splitting on spaces (and handling of quotes etc) happens in the
shell.
An array by definition is already split. On what basis is it split?
Computer Nerd Kev <not@telling.you.invalid> wrote:
It could have been the same with ext* forbidding newlines (also tmpfs
etc.). Then you'd only have to worry about handling newlines in the
rare case of reading from some non-Linux filesystems like UFS.
Could ext* have forbade newlines? Yes. But that would have gone
against years of Unix tradition at the time had it done so. Since
Linux began as a "clone of Unix" it was only natural for it to inherit
Unix traditions as to filenames (any byte value other than ASCII NULL
and ASCII forward slash being allowed).
On 2025-05-06, c186282 <c186282@nnada.net> wrote:
I don't have any Win boxes - Linux or BSD. Same
for decades now.
DID kinda like Win2k ... last "simple" incarnation.
IMHO Windows' usability peaked somewhere between 2k and XP
and has been going downhill ever since.
But ... MAY have a VM of it, maybe, for fun.
I run XP under VirtualBox. It's enough for what Windows
development I do, and is minimally obnoxious.
... and it would have avoided needing lots of special handling for
newlines in software.
On 7 May 2025 09:54:09 +1000, Computer Nerd Kev wrote:
... and it would have avoided needing lots of special handling for
newlines in software.
It’s really only command languages that might have trouble, not proper programming languages.
And even a command language like bash has facilities that can take this
in its stride.
The Natural Philosopher <tnp@invalid.invalid> wrote:
On 04/05/2025 14:41, Richard Kettlewell wrote:
I mean you can trace the transmission of the command line from parent to >>> child process through the startup. There’s no splitting in there, it’s >>> an array of strings from top to bottom.
But the command line is not an array of strings... any more than this
line of text is. That's what I don't understand. It's a single string
The shell (bash/csh/tcsh/ksh/ash/etc.) reads a line of text from you
when you type it in and press return/enter.
The splitting on spaces (and handling of quotes etc) happens in the
shell.
An array by definition is already split. On what basis is it split?
The shell performs the "splitting" from a "line of text" into
individual strings.
All of the kernel, C the language, and libc the library routines
handles the "command line" values as an array of strings.
The shell that reads in that line from you is what splits it up to make
it compatible with the kernel/C/libc interface.
Or, said another way, the shell (bash/csh/etc) is the "translator" from "single line of text" into "array of strings" that the rest of the
interface expects to receive.
Rich <rich@example.invalid> wrote:
Computer Nerd Kev <not@telling.you.invalid> wrote:
It could have been the same with ext* forbidding newlines (also tmpfs
etc.). Then you'd only have to worry about handling newlines in the
rare case of reading from some non-Linux filesystems like UFS.
Could ext* have forbade newlines? Yes. But that would have gone
against years of Unix tradition at the time had it done so. Since
Linux began as a "clone of Unix" it was only natural for it to inherit
Unix traditions as to filenames (any byte value other than ASCII NULL
and ASCII forward slash being allowed).
Well the original quote from Torvalds was about case insensitive
filesystems, which also already have a tradition, but he doesn't
like them, with good reasons. I feel there are valid reasons to
dislike newlines in filenames too. Maybe that would have been too
radical for a UNIX-based OS filesystem, but in practice I can't see
how it would have caused much trouble, and it would have avoided
needing lots of special handling for newlines in software.
Rich <rich@example.invalid> wrote:
Computer Nerd Kev <not@telling.you.invalid> wrote:
It could have been the same with ext* forbidding newlines (also tmpfs
etc.). Then you'd only have to worry about handling newlines in the
rare case of reading from some non-Linux filesystems like UFS.
Could ext* have forbade newlines? Yes. But that would have gone
against years of Unix tradition at the time had it done so. Since
Linux began as a "clone of Unix" it was only natural for it to inherit
Unix traditions as to filenames (any byte value other than ASCII NULL
and ASCII forward slash being allowed).
Well the original quote from Torvalds was about case insensitive
filesystems, which also already have a tradition, but he doesn't
like them, with good reasons. I feel there are valid reasons to
dislike newlines in filenames too. Maybe that would have been too
radical for a UNIX-based OS filesystem, but in practice I can't see
how it would have caused much trouble, and it would have avoided
needing lots of special handling for newlines in software.
Really it's too late for either argument to win now though.
not@telling.you.invalid (Computer Nerd Kev) writes:
Rich <rich@example.invalid> wrote:
Computer Nerd Kev <not@telling.you.invalid> wrote:
It could have been the same with ext* forbidding newlines (also tmpfs
etc.). Then you'd only have to worry about handling newlines in the
rare case of reading from some non-Linux filesystems like UFS.
Could ext* have forbade newlines? Yes. But that would have gone
against years of Unix tradition at the time had it done so. Since
Linux began as a "clone of Unix" it was only natural for it to inherit
Unix traditions as to filenames (any byte value other than ASCII NULL
and ASCII forward slash being allowed).
Well the original quote from Torvalds was about case insensitive
filesystems, which also already have a tradition, but he doesn't
like them, with good reasons. I feel there are valid reasons to
dislike newlines in filenames too. Maybe that would have been too
radical for a UNIX-based OS filesystem, but in practice I can't see
how it would have caused much trouble, and it would have avoided
needing lots of special handling for newlines in software.
Forbidding newlines in extfs and its successors would be straightforward indeed - no harder than forbidding ‘/’ in filenames. But as well as swimming against the Unix tide it wouldn’t actually eliminate the higher-level problem that shell copes badly with filenames with spaces, newlines, etc, since there’s more to life than Linux’s native
filesystem. Early versions of Linux used the Minix filesystem, and today
the kernel includes a large collection of ‘foreign’ filesystems.
Using almost any other language than shell, on the other hand, makes the problem go away.
On 2025-05-07 12:00, Richard Kettlewell wrote:
not@telling.you.invalid (Computer Nerd Kev) writes:
Rich <rich@example.invalid> wrote:
Computer Nerd Kev <not@telling.you.invalid> wrote:
It could have been the same with ext* forbidding newlines (also tmpfs >>>>> etc.). Then you'd only have to worry about handling newlines in the >>>>> rare case of reading from some non-Linux filesystems like UFS.
Could ext* have forbade newlines? Yes. But that would have gone
against years of Unix tradition at the time had it done so. Since
Linux began as a "clone of Unix" it was only natural for it to inherit >>>> Unix traditions as to filenames (any byte value other than ASCII NULL
and ASCII forward slash being allowed).
Well the original quote from Torvalds was about case insensitive
filesystems, which also already have a tradition, but he doesn't
like them, with good reasons. I feel there are valid reasons to
dislike newlines in filenames too. Maybe that would have been too
radical for a UNIX-based OS filesystem, but in practice I can't see
how it would have caused much trouble, and it would have avoided
needing lots of special handling for newlines in software.
Forbidding newlines in extfs and its successors would be straightforward
indeed - no harder than forbidding ‘/’ in filenames. But as well as
swimming against the Unix tide it wouldn’t actually eliminate the
higher-level problem that shell copes badly with filenames with spaces,
newlines, etc, since there’s more to life than Linux’s native
filesystem. Early versions of Linux used the Minix filesystem, and today
the kernel includes a large collection of ‘foreign’ filesystems.
Using almost any other language than shell, on the other hand, makes the
problem go away.
Except if you hardcode a filename inside a C program, for instance. You
still have to escape the quotes.
On 07/05/2025 11:12, Carlos E.R. wrote:
On 2025-05-07 12:00, Richard Kettlewell wrote:That's a different issue: The solution is to construct the name as an
not@telling.you.invalid (Computer Nerd Kev) writes:
Rich <rich@example.invalid> wrote:
Computer Nerd Kev <not@telling.you.invalid> wrote:
It could have been the same with ext* forbidding newlines (also tmpfs >>>>>> etc.). Then you'd only have to worry about handling newlines in the >>>>>> rare case of reading from some non-Linux filesystems like UFS.
Could ext* have forbade newlines? Yes. But that would have gone
against years of Unix tradition at the time had it done so. Since
Linux began as a "clone of Unix" it was only natural for it to inherit >>>>> Unix traditions as to filenames (any byte value other than ASCII NULL >>>>> and ASCII forward slash being allowed).
Well the original quote from Torvalds was about case insensitive
filesystems, which also already have a tradition, but he doesn't
like them, with good reasons. I feel there are valid reasons to
dislike newlines in filenames too. Maybe that would have been too
radical for a UNIX-based OS filesystem, but in practice I can't see
how it would have caused much trouble, and it would have avoided
needing lots of special handling for newlines in software.
Forbidding newlines in extfs and its successors would be straightforward >>> indeed - no harder than forbidding ‘/’ in filenames. But as well as
swimming against the Unix tide it wouldn’t actually eliminate the
higher-level problem that shell copes badly with filenames with spaces,
newlines, etc, since there’s more to life than Linux’s native
filesystem. Early versions of Linux used the Minix filesystem, and today >>> the kernel includes a large collection of ‘foreign’ filesystems.
Using almost any other language than shell, on the other hand, makes the >>> problem go away.
Except if you hardcode a filename inside a C program, for instance.
You still have to escape the quotes.
octal character array.
I had finally figured out that without the shell there *is* no
command line.
Second, the issue in shell is is that newlines (or spaces) interact
badly with its approach to string handling: a filename can cause a
script to unexpectedly fail.
There's no ultimate solution to *that* problem, though - any system for representing a delimited sequence of tokens where the delimiter itself
is a valid token is gonna run into this at *some* point. (It's escape characters all the way down...)
On 2025-05-07 12:00, Richard Kettlewell wrote:
Forbidding newlines in extfs and its successors would be
straightforward indeed - no harder than forbidding ‘/’ in
filenames. But as well as swimming against the Unix tide it wouldn’t
actually eliminate the higher-level problem that shell copes badly
with filenames with spaces, newlines, etc, since there’s more to life
than Linux’s native filesystem. Early versions of Linux used the
Minix filesystem, and today the kernel includes a large collection of
‘foreign’ filesystems.
Using almost any other language than shell, on the other hand, makes
the problem go away.
Except if you hardcode a filename inside a C program, for
instance. You still have to escape the quotes.
On 2025-05-07 13:17, The Natural Philosopher wrote:
The solution is to construct the name as an octal character array.
LOL! What a solution. Very readable :-D
"Carlos E.R." <robin_listas@es.invalid> writes:
On 2025-05-07 12:00, Richard Kettlewell wrote:
Forbidding newlines in extfs and its successors would be
straightforward indeed - no harder than forbidding ‘/’ in
filenames. But as well as swimming against the Unix tide it wouldn’t
actually eliminate the higher-level problem that shell copes badly
with filenames with spaces, newlines, etc, since there’s more to life
than Linux’s native filesystem. Early versions of Linux used the
Minix filesystem, and today the kernel includes a large collection of
‘foreign’ filesystems.
Using almost any other language than shell, on the other hand, makes
the problem go away.
Except if you hardcode a filename inside a C program, for
instance. You still have to escape the quotes.
I’m not sure what you mean. First, no quotes need escaping.
FILE *fp = fopen("whatever\n", "r");
i.e. the normal way of representing newlines in C programs.
Second, the issue in shell is is that newlines (or spaces) interact
badly with its approach to string handling: a filename can cause a
script to unexpectedly fail. For all that C has truly awful string
handling, it doesn’t go awry just because there’s a space or newline in
a string that it’s working with.
(Strings with nulls in are another matter, but not relevant to filenames
in Unix filesystems, and AFAIK not common anywhere either.)
On 2025-05-07 13:17, The Natural Philosopher wrote:
On 07/05/2025 11:12, Carlos E.R. wrote:
On 2025-05-07 12:00, Richard Kettlewell wrote:That's a different issue: The solution is to construct the name as an
not@telling.you.invalid (Computer Nerd Kev) writes:
Rich <rich@example.invalid> wrote:
Computer Nerd Kev <not@telling.you.invalid> wrote:
It could have been the same with ext* forbidding newlines (also
tmpfs
etc.). Then you'd only have to worry about handling newlines in the >>>>>>> rare case of reading from some non-Linux filesystems like UFS.
Could ext* have forbade newlines? Yes. But that would have gone >>>>>> against years of Unix tradition at the time had it done so. Since >>>>>> Linux began as a "clone of Unix" it was only natural for it to
inherit
Unix traditions as to filenames (any byte value other than ASCII NULL >>>>>> and ASCII forward slash being allowed).
Well the original quote from Torvalds was about case insensitive
filesystems, which also already have a tradition, but he doesn't
like them, with good reasons. I feel there are valid reasons to
dislike newlines in filenames too. Maybe that would have been too
radical for a UNIX-based OS filesystem, but in practice I can't see
how it would have caused much trouble, and it would have avoided
needing lots of special handling for newlines in software.
Forbidding newlines in extfs and its successors would be
straightforward
indeed - no harder than forbidding ‘/’ in filenames. But as well as >>>> swimming against the Unix tide it wouldn’t actually eliminate the
higher-level problem that shell copes badly with filenames with spaces, >>>> newlines, etc, since there’s more to life than Linux’s native
filesystem. Early versions of Linux used the Minix filesystem, and
today
the kernel includes a large collection of ‘foreign’ filesystems.
Using almost any other language than shell, on the other hand, makes
the
problem go away.
Except if you hardcode a filename inside a C program, for instance.
You still have to escape the quotes.
octal character array.
LOL! What a solution. Very readable :-D
Second, the issue in shell is is that newlines (or spaces) interact
badly with its approach to string handling: a filename can cause a
script to unexpectedly fail. For all that C has truly awful string
handling, it doesn't go awry just because there's a space or newline in
a string that it's working with.
Richard Kettlewell <invalid@invalid.invalid> wrote:
Second, the issue in shell is is that newlines (or spaces) interact
badly with its approach to string handling: a filename can cause a
script to unexpectedly fail. For all that C has truly awful string
handling, it doesn't go awry just because there's a space or newline in
a string that it's working with.
When dealing with programs like find, sort, uniq etc. it's more of a
data format issue than a shell issue. As in the link from the GNU
find documentation which I supplied before where "find" apparantly
runs "sort" itself and needs that to support null-terminated line
delimiters to handle newlines in filenames, rather than the default newline-terminated format:
http://www.gnu.org/software/findutils/manual/html_node/find_html/Newline-Handling.html
Of course a C program can use any character to separate strings
but newlines are most common in existing UNIX tools for text string processing,
and most easily human-readable, so it's convenient to use
that data format.
But it means assuming that newlines in filenames won't actually
appear.
On 07/05/2025 22:41, Richard Kettlewell wrote:
(Strings with nulls in are another matter, but not relevant to
filenames in Unix filesystems, and AFAIK not common anywhere
either.)
Well again, how do you process a Jpeg read into a program? Or a raw
disc sector, or a stream of comms containing binary data?
Ultimately C strings are not, unlike left wing 'progressive' politics,
or PASCAL types, something that is imposed on you. You have the choice.
Computer Nerd Kev <not@telling.you.invalid> wrote:
Richard Kettlewell <invalid@invalid.invalid> wrote:
Second, the issue in shell is is that newlines (or spaces) interact
badly with its approach to string handling: a filename can cause a
script to unexpectedly fail. For all that C has truly awful string
handling, it doesn't go awry just because there's a space or newline in
a string that it's working with.
When dealing with programs like find, sort, uniq etc. it's more of a
data format issue than a shell issue. As in the link from the GNU
find documentation which I supplied before where "find" apparantly
runs "sort" itself and needs that to support null-terminated line
delimiters to handle newlines in filenames, rather than the default
newline-terminated format:
http://www.gnu.org/software/findutils/manual/html_node/find_html/Newline-Handling.html
That is not the "find" documentation, that is the documentation for locate/updatedb and the db format they use to make locating a filename
faster than a raw disk scan. That 'running of sort' is done by
'updatedb', not find.
Of course a C program can use any character to separate strings
A C program uses (if it uses libc's string routines) ASCII nulls to
mark the end of a C string in memory. Of course if you want to build
your own "C string" library (C's strings are provided by libc, not the
C language itself) you can choose to delimit strings however you wish.
But it means assuming that newlines in filenames won't actually
appear.
Which, in reality, is all but true unless someone is going out of their
way to experiment or be very odd. The only time I've ever encountered filenames with newlines has been when I've deliberately created them to verify some bit of code (or to try to break some bit of code, although verify/break often go hand in hand).
Linus ALLOWED long, case/space, sensitive
file systems.
NOW we're STUCK with them ... AND all the
various downsides. CAN'T go back even if
it's the better thing.
Linux implemented a roughly UNIX compatible OS. And that was the right
thing to do.
Richard Kettlewell <invalid@invalid.invalid> wrote:
Second, the issue in shell is is that newlines (or spaces) interact
badly with its approach to string handling: a filename can cause a
script to unexpectedly fail. For all that C has truly awful string
handling, it doesn't go awry just because there's a space or newline in
a string that it's working with.
When dealing with programs like find, sort, uniq etc. it's more of
a data format issue than a shell issue.
Of course a C program can use any character to separate strings,
but newlines are most common in existing UNIX tools for text string processing, and most easily human-readable, so it's convenient to
use that data format. But it means assuming that newlines in
filenames won't actually appear.
Look people ...Cost benefit analysis.
Everyone is just ARGUING.
FACTs are what they are.
Linus ALLOWED long, case/space, sensitive
file systems.
NOW we're STUCK with them ... AND all the
various downsides. CAN'T go back even if
it's the better thing.
Rich <rich@example.invalid> wrote:
Computer Nerd Kev <not@telling.you.invalid> wrote:
But it means assuming that newlines in filenames won't actually
appear.
Which, in reality, is all but true unless someone is going out of
their way to experiment or be very odd. The only time I've ever
encountered filenames with newlines has been when I've deliberately
created them to verify some bit of code (or to try to break some bit
of code, although verify/break often go hand in hand).
That's my point exactly, all these work-arounds in specific programs
like "find -print0" in GNU Find have been written even though use of
newlines in filenames is so rare.
We'd have been better off with newlines forbidden in filenames so
that all the special handling just for the sake of someone "going out
of their way to experiment or be very odd" could be avoided.
Probably more secure against people hacking software whose authors
didn't think about it too.
Yes it's too late to change now, _someone_ will be using filenames
with newlines in a major way, but I'd say the same about the case insensitivity feature which "Torvalds Hates".
c186282 <c186282@nnada.net> wrote:
Linus ALLOWED long, case/space, sensitive file systems.
NOW we're STUCK with them ... AND all the various downsides. CAN'T
go back even if it's the better thing.
Linux implemented a roughly UNIX compatible OS. And that was the right
thing to do.
If someone wants to complain about "X allowed newlines" they likely
need to go way back to Bell Labs and Kernigan and Ritchie and ask them
why they allowed, effectively, any character to be in a filename.
On 2025-05-08, Rich <rich@example.invalid> wrote:
If someone wants to complain about "X allowed newlines" they likely
need to go way back to Bell Labs and Kernigan and Ritchie and ask them
why they allowed, effectively, any character to be in a filename.
I wouldn't be surprised that they never gave the matter much thought,
outside of disallowing NULs and slashes. That's where your "effectively" comes in above. They probably assumed that nobody in his right mind would
use newlines unless he knew what he was doing, had a good reason for it,
and was ready to take responsibility for his actions.
Unix and C have a long tradition of giving users enough rope to hang themselves with. For skilled people, it's less hassle than trying to
work around all sorts of arbitrary restrictions designed to protect
users from themselves. The rise of the nanny state has made this
approach less popular...
Charlie Gibbs <cgibbs@kltpzyxm.invalid> wrote:
I wouldn't be surprised that they never gave the matter much thought,
outside of disallowing NULs and slashes. That's where your "effectively"
comes in above. They probably assumed that nobody in his right mind would
use newlines unless he knew what he was doing, had a good reason for it,
and was ready to take responsibility for his actions.
That's my belief, but not having been there, and having no way to ask
them, that's all it is. But most likely reason is simply they did not consider limiting the characters that could be used in any way.
Also modern versions of the tools have long since recognized this and sprouted options for separating input elements with nulls. That still
leaves them unsuitable for completely general data processing ...
Computer Nerd Kev <not@telling.you.invalid> wrote:
Rich <rich@example.invalid> wrote:
Computer Nerd Kev <not@telling.you.invalid> wrote:
But it means assuming that newlines in filenames won't actually
appear.
Which, in reality, is all but true unless someone is going out of
their way to experiment or be very odd. The only time I've ever
encountered filenames with newlines has been when I've deliberately
created them to verify some bit of code (or to try to break some bit
of code, although verify/break often go hand in hand).
That's my point exactly, all these work-arounds in specific programs
like "find -print0" in GNU Find have been written even though use of
newlines in filenames is so rare.
The -print0 "workaround" as you call it is not there "just for
newlines". Banning newlines would not help with the need for -print0. -print0 also helps with preventing all the other shell metacharacters
and spaces from also causing trouble when piping filenames through all
the various tools.
We'd have been better off with newlines forbidden in filenames so
that all the special handling just for the sake of someone "going out
of their way to experiment or be very odd" could be avoided.
Probably more secure against people hacking software whose authors
didn't think about it too.
Forbidding newlines would not fix the need for -print0. You'd also
need to forbid an entire host of printable characters (many of which unsuspecting users will try to use, such as ASCII single quote ' for a contraction in a filename). You'd either need to ban things like '
and $ and " and others - and as soon as you go down that path it's
almost a bottomless hole until you've banned everything but [a-z0-9.].
Yes it's too late to change now, _someone_ will be using filenames
with newlines in a major way, but I'd say the same about the case
insensitivity feature which "Torvalds Hates".
I very much doubt anyone actually "uses newlines" in a filename (other
than for testing that something does not break when they are
encountered).
They probably assumed that nobody in his right mind would
use newlines unless he knew what he was doing, had a good reason for it,
and was ready to take responsibility for his actions.
But given the general sense of “we provide mechanism, not policy” it’s plausible they’d have said the same applies to names, if asked.
Rich <rich@example.invalid> wrote:
Computer Nerd Kev <not@telling.you.invalid> wrote:
Rich <rich@example.invalid> wrote:
Computer Nerd Kev <not@telling.you.invalid> wrote:
But it means assuming that newlines in filenames won't actually
appear.
Which, in reality, is all but true unless someone is going out of
their way to experiment or be very odd. The only time I've ever
encountered filenames with newlines has been when I've deliberately
created them to verify some bit of code (or to try to break some bit
of code, although verify/break often go hand in hand).
That's my point exactly, all these work-arounds in specific programs
like "find -print0" in GNU Find have been written even though use of
newlines in filenames is so rare.
The -print0 "workaround" as you call it is not there "just for
newlines". Banning newlines would not help with the need for -print0.
-print0 also helps with preventing all the other shell metacharacters
and spaces from also causing trouble when piping filenames through all
the various tools.
No, the GNU Find man page says:
"-print0, -fprint0
Always print the exact filename, unchanged, even if the output is
going to a terminal."
Which is the same as the default -print if the output isn't to a
terminal, except -print0 uses null instead of newline to separate
filenames because they're a particular problem. Other special
characters aren't as problematic.
Wouldn't it be fucking wonderful if politicians did the same?
All characters that are allowed can be problematic if they're being used
as the separator.
No, the GNU Find man page says:
"-print0, -fprint0
Always print the exact filename, unchanged, even if the output is
going to a terminal."
Which is the same as the default -print if the output isn't to a
terminal, except -print0 uses null instead of newline to separate
filenames because they're a particular problem. Other special
characters aren't as problematic.
Marc Haber <mh+usenetspam1118@zugschl.us> wrote:
c186282 <c186282@nnada.net> wrote:
Linus ALLOWED long, case/space, sensitive file systems.
NOW we're STUCK with them ... AND all the various downsides. CAN'T
go back even if it's the better thing.
Linux implemented a roughly UNIX compatible OS. And that was the right
thing to do.
Which was my point to Computer Nerd Kevin several replies upthread.
Linus didn't decide himself to "allow newlines" (really to "allow
everything" but ASCII / and ASCII null), he just followed what was
standard practice in the rest of the Unix world.
If someone wants to complain about "X allowed newlines" they likely
need to go way back to Bell Labs and Kernigan and Ritchie and ask them
why they allowed, effectively, any character to be in a filename.
not@telling.you.invalid (Computer Nerd Kev) wrote:
No, the GNU Find man page says:
"-print0, -fprint0
Always print the exact filename, unchanged, even if the output is
going to a terminal."
Which is the same as the default -print if the output isn't to a
terminal, except -print0 uses null instead of newline to separate
filenames because they're a particular problem. Other special
characters aren't as problematic.
The shell tokenizes at whitespace, and a newline is often treated as whitespace. -print0 is the canonical protection that makes your script
handle spaces in newlines correctly, and THOSE are rather common in
file names. Look in your music directory for examples.
You've gotten yourself into something in this discussion. Better take
a step back to stop embarrassing yourself.
The shell tokenizes at whitespace, and a newline is often treated as whitespace.
Rich <rich@example.invalid> wrote:
The -print0 "workaround" as you call it is not there "just for
newlines". Banning newlines would not help with the need for -print0.
-print0 also helps with preventing all the other shell metacharacters
and spaces from also causing trouble when piping filenames through all
the various tools.
No, the GNU Find man page says:
"-print0, -fprint0
Always print the exact filename, unchanged, even if the output is
going to a terminal."
Which is the same as the default -print if the output isn't to a
terminal, except -print0 uses null instead of newline to separate
filenames because they're a particular problem. Other special
characters aren't as problematic.
On Fri, 09 May 2025 07:06:56 +0200, Marc Haber wrote:
The shell tokenizes at whitespace, and a newline is often treated as
whitespace.
The shell does word splitting (not quite tokenization) at “internal field >separators”.
On Fri, 9 May 2025 00:28:33 +0100, The Natural Philosopher wrote:
Wouldn't it be fucking wonderful if politicians did the same?
They do whatever we vote for them to do.
On 09/05/2025 19:05, Charlie Gibbs wrote:
On 2025-05-09, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
On Fri, 9 May 2025 00:28:33 +0100, The Natural Philosopher wrote:
Wouldn't it be fucking wonderful if politicians did the same?
They do whatever we vote for them to do.
On election day, perhaps. After that, they do whatever they
damn well please.
Indeed.
Morden politics consists of:
- working out what the public wants
- telling them you are going to do it
- getting elected
- lining your pockets
- lining the pockets of those who paid off the people necessary to get
you elected.
- lying to the public about why you couldn't do - or are doing - what
they wanted, when you patently are not.
Dictatorships simple omit the first three steps.
On 2025-05-09, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
On Fri, 9 May 2025 00:28:33 +0100, The Natural Philosopher wrote:
Wouldn't it be fucking wonderful if politicians did the same?
They do whatever we vote for them to do.
On election day, perhaps. After that, they do whatever they
damn well please.
On 2025-05-09, The Natural Philosopher <tnp@invalid.invalid> wrote:
On 09/05/2025 19:05, Charlie Gibbs wrote:
On 2025-05-09, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
On Fri, 9 May 2025 00:28:33 +0100, The Natural Philosopher wrote:
Wouldn't it be fucking wonderful if politicians did the same?
They do whatever we vote for them to do.
On election day, perhaps. After that, they do whatever they
damn well please.
Indeed.
Morden politics consists of:
- working out what the public wants
- telling them you are going to do it
- getting elected
- lining your pockets
- lining the pockets of those who paid off the people necessary to get
you elected.
- lying to the public about why you couldn't do - or are doing - what
they wanted, when you patently are not.
Dictatorships simple omit the first three steps.
Transition between the two is done via what I call the Final Vote.
That's where people democratically elect someone who then dismantles
the democratic framework.
On Thu, 08 May 2025 09:22:51 +0100, Richard Kettlewell wrote:
Also modern versions of the tools have long since recognized this and
sprouted options for separating input elements with nulls. That still
leaves them unsuitable for completely general data processing ...
Some tools are also offering the option for JSON-format output.
Transition between the two is done via what I call the Final Vote.
That's where people democratically elect someone who then dismantles the democratic framework.
On 2025-05-09, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
On Fri, 9 May 2025 00:28:33 +0100, The Natural Philosopher wrote:
Wouldn't it be fucking wonderful if politicians did the same?
They do whatever we vote for them to do.
On election day, perhaps. After that, they do whatever they damn well please.
As far as filenames go, no one is *forcing* you to use case sensitivity spaces or dashes, only Left wing people tend to do that, because they
think they know better.
Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
On Fri, 09 May 2025 07:06:56 +0200, Marc Haber wrote:
The shell tokenizes at whitespace, and a newline is often treated as
whitespace.
The shell does word splitting (not quite tokenization) at “internal
field separators”.
And the default is whitespace.
Have a look at the parsing rules for xargs or the shell
read builtin. They are much more complicated than using newlines as a separator.
On 5/8/25 23:58, Lawrence D'Oliveiro wrote:
Some tools are also offering the option for JSON-format output.
There us also a utility jc.
On Fri, 09 May 2025 18:05:00 GMT, Charlie Gibbs wrote:
On 2025-05-09, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
On Fri, 9 May 2025 00:28:33 +0100, The Natural Philosopher wrote:
Wouldn't it be fucking wonderful if politicians did the same?
They do whatever we vote for them to do.
On election day, perhaps. After that, they do whatever they damn well
please.
Whatever promises they do or don’t keep, come back to bite them next election day.
At least, that’s how it works in functioning democracies.
On 2025-05-09, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
At least, that’s how it works in functioning democracies.
I'd love to see one of those.
This is also why the first thing a would-be dictator does once elected
is to start dismantling - or bypassing - those checks and balances.
The late John W. Campbell, in one of his thought-provoking
editorials in Analog Science Fact<->Fiction in the 1960s,
pointed out that it's not power that corrupts. People are
much less likely to abuse power if they can be held accountable ...
On Fri, 09 May 2025 20:31:20 GMT, Charlie Gibbs wrote:
Transition between the two is done via what I call the Final Vote.
That's where people democratically elect someone who then dismantles
the democratic framework.
This is why checks and balances are so important: an impartial judiciary
and an independent and free press are both vital. That majority vote is necessary, but not sufficient.
Le 07-05-2025, The Natural Philosopher <tnp@invalid.invalid> a écrit :
As far as filenames go, no one is *forcing* you to use case sensitivity
spaces or dashes, only Left wing people tend to do that, because they
think they know better.
OK, now I understand why your pseudo says you are a philosopher. It's to
make believe your messages aren't made by your ass.
On Fri, 09 May 2025 23:55:40 GMT, Charlie Gibbs wrote:
On 2025-05-09, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
At least, that’s how it works in functioning democracies.
I'd love to see one of those.
People in the US automatically assume that they are the best in the world
at everything, so if they suck at something, nobody else could possibly be doing it better, could they?
Some of the many countries that enjoy greater press freedom than the USA: Trinidad and Tobago, Jamaica, South Africa, Tonga, Liberia.
The late John W. Campbell, in one of his thought-provoking
editorials in Analog Science Fact<->Fiction in the 1960s,
pointed out that it's not power that corrupts. People are
much less likely to abuse power if they can be held accountable
(which is why the A-word is hated and feared among politicians).
Campbell suggested re-writing the old saying as follows:
Immunity corrupts; absolute immunity corrupts absolutely.
Le 09-05-2025, Charlie Gibbs <cgibbs@kltpzyxm.invalid> a écrit :
The late John W. Campbell, in one of his thought-provoking
editorials in Analog Science Fact<->Fiction in the 1960s,
pointed out that it's not power that corrupts. People are
much less likely to abuse power if they can be held accountable
It's not that new. Platon already spoke about this with his invisibility ring. But that's not the reason I answered you. The reason is:
(which is why the A-word is hated and feared among politicians).
Sorry, I'm French and I really don't know what the A-word could be.
On 2025-05-10, Stéphane CARPENTIER <sc@fiat-linux.fr> wrote:
Le 09-05-2025, Charlie Gibbs <cgibbs@kltpzyxm.invalid> a écrit :
The late John W. Campbell, in one of his thought-provoking editorials
in Analog Science Fact<->Fiction in the 1960s, pointed out that it's
not power that corrupts. People are much less likely to abuse power
if they can be held accountable
It's not that new. Platon already spoke about this with his
invisibility ring. But that's not the reason I answered you. The reason
is:
(which is why the A-word is hated and feared among politicians).
Sorry, I'm French and I really don't know what the A-word could be.
Accountability. Politicians talk a good line about openness,
transparency, accountability, etc. - but in actual fact they hate and
fear these things, and work tirelessly (and usually clandestinely) to minimize these threats to their power by building immunity.
On 5/8/25 23:58, Lawrence D'Oliveiro wrote:
On Thu, 08 May 2025 09:22:51 +0100, Richard Kettlewell wrote:
Also modern versions of the tools have long since recognized this and
sprouted options for separating input elements with nulls. That still
leaves them unsuitable for completely general data processing ...
Some tools are also offering the option for JSON-format output.
There us also a utility jc.
jc - JSON Convert JSONifies the output of many CLI tools, file-types,
and strings
On Sat, 10 May 2025 18:14:34 GMT, Charlie Gibbs wrote:
On 2025-05-10, Stéphane CARPENTIER <sc@fiat-linux.fr> wrote:
Le 09-05-2025, Charlie Gibbs <cgibbs@kltpzyxm.invalid> a écrit :
The late John W. Campbell, in one of his thought-provoking editorials
in Analog Science Fact<->Fiction in the 1960s, pointed out that it's
not power that corrupts. People are much less likely to abuse power
if they can be held accountable
It's not that new. Platon already spoke about this with his
invisibility ring. But that's not the reason I answered you. The reason
is:
(which is why the A-word is hated and feared among politicians).
Sorry, I'm French and I really don't know what the A-word could be.
Accountability.
Politicians talk a good line about openness, transparency,
accountability, etc. - but in actual fact they hate and fear these
things, and work tirelessly (and usually clandestinely) to minimize
these threats to their power by building immunity.
My first thought was 'Anarchism'.
Politicians despise the thought that people can organize themselves
without their enlightened guidance. I'll admit that once you go beyond
the theoretical there have always been implementation problems but the
answer is not more and more centralized power.
And when she is proven to
have stolen €3.5 million (almost US$4 millions) she says that it's undemocratic to condamne her. Do what I say, not what I do, yes, I
agree.
On Sat, 10 May 2025 18:14:34 GMT, Charlie Gibbs wrote:
On 2025-05-10, Stéphane CARPENTIER <sc@fiat-linux.fr> wrote:
Le 09-05-2025, Charlie Gibbs <cgibbs@kltpzyxm.invalid> a écrit :
The late John W. Campbell, in one of his thought-provoking editorials
in Analog Science Fact<->Fiction in the 1960s, pointed out that it's
not power that corrupts. People are much less likely to abuse power
if they can be held accountable
It's not that new. Platon already spoke about this with his
invisibility ring. But that's not the reason I answered you. The reason
is:
(which is why the A-word is hated and feared among politicians).
Sorry, I'm French and I really don't know what the A-word could be.
Accountability. Politicians talk a good line about openness,
transparency, accountability, etc. - but in actual fact they hate and
fear these things, and work tirelessly (and usually clandestinely) to
minimize these threats to their power by building immunity.
My first thought was 'Anarchism'. Politicians despise the thought that
people can organize themselves without their enlightened guidance. I'll
admit that once you go beyond the theoretical there have always been implementation problems but the answer is not more and more centralized power.
On Fri, 9 May 2025 21:54:10 +0100, Pancho wrote:
On 5/8/25 23:58, Lawrence D'Oliveiro wrote:
Some tools are also offering the option for JSON-format output.
There us also a utility jc.
Useful for manipulating such output. Though I haven’t quite got my head around when a conditional expression is used to filter output, and when
it is used to output boolean values ...
System theory show a centralised feedback system either fails to respond
to change or goes unstable.
On 10/05/2025 21:05, rbowman wrote:
On Sat, 10 May 2025 18:14:34 GMT, Charlie Gibbs wrote:
On 2025-05-10, Stéphane CARPENTIER <sc@fiat-linux.fr> wrote:
Le 09-05-2025, Charlie Gibbs <cgibbs@kltpzyxm.invalid> a écrit :
The late John W. Campbell, in one of his thought-provoking editorials >>>>> in Analog Science Fact<->Fiction in the 1960s, pointed out that it's >>>>> not power that corrupts. People are much less likely to abuse power >>>>> if they can be held accountable
It's not that new. Platon already spoke about this with his
invisibility ring. But that's not the reason I answered you. The reason >>>> is:
(which is why the A-word is hated and feared among politicians).
Sorry, I'm French and I really don't know what the A-word could be.
Accountability. Politicians talk a good line about openness,
transparency, accountability, etc. - but in actual fact they hate and
fear these things, and work tirelessly (and usually clandestinely) to
minimize these threats to their power by building immunity.
My first thought was 'Anarchism'. Politicians despise the thought that
people can organize themselves without their enlightened guidance. I'll
admit that once you go beyond the theoretical there have always been
implementation problems but the answer is not more and more centralized
power.
No.
There are even signs that King Donald is beginning to realise that.
System theory show a centralised feedback system either fails to respond
to change or goes unstable.
You need local systems with clearly defined feedback paths and responsibilities and a light touch of overall guidance.
On 10/05/2025 22:05, Stéphane CARPENTIER wrote:
And when she is proven to
have stolen €3.5 million (almost US$4 millions) she says that it's
undemocratic to condamne her. Do what I say, not what I do, yes, I
agree.
Stolen from whom?
Where is it now?In the pockets of the party or her's.
On Fri, 9 May 2025 21:55:54 -0000 (UTC), Lawrence D'Oliveiro wrote:
On Fri, 9 May 2025 21:54:10 +0100, Pancho wrote:
On 5/8/25 23:58, Lawrence D'Oliveiro wrote:
Some tools are also offering the option for JSON-format output.
There us also a utility jc.
Useful for manipulating such output. Though I haven’t quite got my head
around when a conditional expression is used to filter output, and when
it is used to output boolean values ...
Ah, sorry, I didn’t notice you said “jc” instead of “jq” ...
On So 11 Mai 2025 at 01:04, The Natural Philosopher <tnp@invalid.invalid> wrote:
On 10/05/2025 22:05, Stéphane CARPENTIER wrote:
And when she is proven to
have stolen €3.5 million (almost US$4 millions) she says that it's
undemocratic to condamne her. Do what I say, not what I do, yes, I
agree.
Stolen from whom?
From the EU.
Where is it now?In the pockets of the party or her's.
'Andreas
On 5/10/25 8:03 PM, The Natural Philosopher wrote:
On 10/05/2025 21:05, rbowman wrote:
On Sat, 10 May 2025 18:14:34 GMT, Charlie Gibbs wrote:
On 2025-05-10, Stéphane CARPENTIER <sc@fiat-linux.fr> wrote:
Le 09-05-2025, Charlie Gibbs <cgibbs@kltpzyxm.invalid> a écrit :
The late John W. Campbell, in one of his thought-provoking editorials >>>>>> in Analog Science Fact<->Fiction in the 1960s, pointed out that it's >>>>>> not power that corrupts. People are much less likely to abuse power >>>>>> if they can be held accountable
It's not that new. Platon already spoke about this with his
invisibility ring. But that's not the reason I answered you. The
reason
is:
(which is why the A-word is hated and feared among politicians).
Sorry, I'm French and I really don't know what the A-word could be.
Accountability. Politicians talk a good line about openness,
transparency, accountability, etc. - but in actual fact they hate and
fear these things, and work tirelessly (and usually clandestinely) to
minimize these threats to their power by building immunity.
My first thought was 'Anarchism'. Politicians despise the thought that
people can organize themselves without their enlightened guidance. I'll
admit that once you go beyond the theoretical there have always been
implementation problems but the answer is not more and more centralized
power.
No.
There are even signs that King Donald is beginning to realise that.
System theory show a centralised feedback system either fails to
respond to change or goes unstable.
You need local systems with clearly defined feedback paths and
responsibilities and a light touch of overall guidance.
Fine, in 1824 Missouri.
However everything has MUCH broader reach/impact
these days.
Sorry, but MORE super-org IS required. Yep, can
sometimes SUCK ... but without it things can suck
even more.
Think about it.
Hmmmm ... now can we leverage Linux to help take
care of all this ?
On 11/05/2025 09:58, Andreas Eder wrote:
On So 11 Mai 2025 at 01:04, The Natural Philosopher <tnp@invalid.invalid> wrote:But *all* EU politicians steal from the EU, which steals from its member states.
On 10/05/2025 22:05, Stéphane CARPENTIER wrote:From the EU.
And when she is proven to
have stolen €3.5 million (almost US$4 millions) she says that it's
undemocratic to condamne her. Do what I say, not what I do, yes, I
agree.
Stolen from whom?
Where is it now?In the pockets of the party or her's.
You obviously have never been to Brussels,
On Fri, 9 May 2025 21:55:54 -0000 (UTC), Lawrence D'Oliveiro wrote:
On Fri, 9 May 2025 21:54:10 +0100, Pancho wrote:
On 5/8/25 23:58, Lawrence D'Oliveiro wrote:
Some tools are also offering the option for JSON-format output.
There us also a utility jc.
Useful for manipulating such output. Though I haven’t quite got my head
around when a conditional expression is used to filter output, and when
it is used to output boolean values ...
Ah, sorry, I didn’t notice you said “jc” instead of “jq” ...
On So 11 Mai 2025 at 11:42, The Natural Philosopher <tnp@invalid.invalid> wrote:
On 11/05/2025 09:58, Andreas Eder wrote:
On So 11 Mai 2025 at 01:04, The Natural Philosopher <tnp@invalid.invalid> wrote:But *all* EU politicians steal from the EU, which steals from its member
On 10/05/2025 22:05, Stéphane CARPENTIER wrote:From the EU.
And when she is proven to
have stolen €3.5 million (almost US$4 millions) she says that it's >>>>> undemocratic to condamne her. Do what I say, not what I do, yes, I
agree.
Stolen from whom?
Where is it now?In the pockets of the party or her's.
states.
That is blatant nonsense.
You obviously have never been to Brussels,
And you are a member of the EU parliament?
Right Wingers often say that all politicians are equally corrupt ...
But *all* EU politicians steal from the EU, which steals from its member states.
Right Wingers often say that all politicians are equally corrupt, so
that left wingers despair and don't vote, and thus the right wing gets
the control.
On Sun, 11 May 2025 11:42:05 +0100, The Natural Philosopher wrote:
But *all* EU politicians steal from the EU, which steals from its
member states.
Just because political corruption happens in your own country, you
assume everybody else is equally corrupt.
I don't think anyone really suggests the EU aren't corrupt.
On Sun, 11 May 2025 21:17:06 +0200, Carlos E.R. wrote:
Right Wingers often say that all politicians are equally corrupt ...
Except theirs, of course.
And of course voters must do their part. It is in the interest of
certain parties to cultivate cynicism in the system on the part of the general public, because this way it undermines the whole system and lets those parties take control, bypassing all the checks and balances. As
seems to have happened in the USA, for example.
On Mon, 12 May 2025 13:04:44 +0100, Pancho wrote:
I don't think anyone really suggests the EU aren't corrupt.
The saying is “power corrupts, and absolutely power corrupts absolutely”.
This is why, in democracies, we have checks and balances: different kinds
of power are given to different groups which are supposed to be
independent of each other, and keep an eye on each other. This includes
the judiciary and the press.
And of course voters must do their part. It is in the interest of certain parties to cultivate cynicism in the system on the part of the general public, because this way it undermines the whole system and lets those parties take control, bypassing all the checks and balances. As seems to
have happened in the USA, for example.
On 2025-05-11 15:24, Andreas Eder wrote:
On So 11 Mai 2025 at 11:42, The Natural Philosopher
<tnp@invalid.invalid> wrote:
On 11/05/2025 09:58, Andreas Eder wrote:
On So 11 Mai 2025 at 01:04, The Natural PhilosopherBut *all* EU politicians steal from the EU, which steals from its member >>> states.
<tnp@invalid.invalid> wrote:
On 10/05/2025 22:05, Stéphane CARPENTIER wrote:From the EU.
And when she is proven to
have stolen €3.5 million (almost US$4 millions) she says that it's >>>>>> undemocratic to condamne her. Do what I say, not what I do, yes, I >>>>>> agree.
Stolen from whom?
Where is it now?In the pockets of the party or her's.
That is blatant nonsense.
You obviously have never been to Brussels,
And you are a member of the EU parliament?
Right Wingers often say that all politicians are equally corrupt, so
that left wingers despair and don't vote, and thus the right wing gets
the control.
On So 11 Mai 2025 at 11:42, The Natural Philosopher <tnp@invalid.invalid> wrote:
On 11/05/2025 09:58, Andreas Eder wrote:
On So 11 Mai 2025 at 01:04, The Natural Philosopher <tnp@invalid.invalid> wrote:But *all* EU politicians steal from the EU, which steals from its member
On 10/05/2025 22:05, Stéphane CARPENTIER wrote:From the EU.
And when she is proven to
have stolen €3.5 million (almost US$4 millions) she says that it's >>>>> undemocratic to condamne her. Do what I say, not what I do, yes, I
agree.
Stolen from whom?
Where is it now?In the pockets of the party or her's.
states.
That is blatant nonsense.
You obviously have never been to Brussels,
And you are a member of the EU parliament?
'Andreas
Democracy doesn't really decide anything, it is only really a safety
pressure valve. Designed to stop government controlled by the elite/establishment diverging from the interests of the public, to the
point the public are so pissed off they start a revolution.
On 5/12/25 23:44, Lawrence D'Oliveiro wrote:
On Mon, 12 May 2025 13:04:44 +0100, Pancho wrote:
I don't think anyone really suggests the EU aren't corrupt.
The saying is “power corrupts, and absolutely power corrupts absolutely”.
No, the current political class, start as corrupt. They train in
political science. They start with the goal of self enrichment, not ideological idealism.
Not really, these structures are not independent, they are dominated by
the establishment. They are designed to protect the establishment,
protect the powerful and entitled from mob rule.
Today, however politicains are not gentlemen. Especially M'sieu L'orange
On Tue, 13 May 2025 11:21:34 +0100, Pancho wrote:
Not really, these structures are not independent, they are dominated by
the establishment. They are designed to protect the establishment,
protect the powerful and entitled from mob rule.
Is your standard of reference the USA? No wonder.
Here in NZ, we just got rid our deputy chief of police, because of certain unsavoury behaviour he was involved with. Note that no criminal charges
have been laid (yet): simply the fact that there is this whiff of
corruption about him was already grounds for dismissal.
That’s how checks and balances should work.
On Tue, 13 May 2025 11:21:34 +0100, Pancho wrote:
Not really, these structures are not independent, they are dominated by
the establishment. They are designed to protect the establishment,
protect the powerful and entitled from mob rule.
Is your standard of reference the USA? No wonder.
Here in NZ, we just got rid our deputy chief of police, because of certain unsavoury behaviour he was involved with. Note that no criminal charges
have been laid (yet): simply the fact that there is this whiff of
corruption about him was already grounds for dismissal.
On 2025-05-14, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
On Tue, 13 May 2025 11:21:34 +0100, Pancho wrote:
Not really, these structures are not independent, they are dominated by
the establishment. They are designed to protect the establishment,
protect the powerful and entitled from mob rule.
Is your standard of reference the USA? No wonder.
Here in NZ, we just got rid our deputy chief of police, because of certain >> unsavoury behaviour he was involved with. Note that no criminal charges
have been laid (yet): simply the fact that there is this whiff of
corruption about him was already grounds for dismissal.
That’s how checks and balances should work.
On the other hand, if that "whiff of corruption" can't be substantiated,
it's a great opportunity for character assassination. This comes in
handy if the powerful want to throw an innocent (but inconvenient) person under the bus.
On Wed, 14 May 2025 21:39:49 +0100, Pancho wrote:
People shouldn't be sacked for a whiff of anything. That encourages
false allegations.
The key being credible allegations. Also, the phrase “no smoke without fire” comes to mind ...
“Innocent until proven guilty” should only apply to private citizens going
about their private affairs. Those who are elected or appointed to a
higher office with statutory power over others need to be held to a higher standard.
People shouldn't be sacked for a whiff of anything. That encourages
false allegations.
On the other hand, if that "whiff of corruption" can't be substantiated,
it's a great opportunity for character assassination.
In the UK, Police management had a history of trumping up charges of misconduct against officers who challenged institutional abuse or
corruption.
No "Innocent until proven guilty" is a fine maxim. The higher standards
in public life should be codified. For instance, there is a fear that
public officials could be induced to implement policies based on
receiving gifts, i.e. bribes. So the higher standard in public life
should be to prevent them receiving gifts, at all. They should be fired
for breaching this rule, independent of any proof the gift was an
inducement, a bribe. It is easier to prove they received a gift, than
that the gift was effectively a bribe. However, there should be proof
they received the gift. We shouldn't fire a public official just because someone makes an unsubstantiated allegation against them.
On Thu, 15 May 2025 00:04:31 +0100, Pancho wrote:
In the UK, Police management had a history of trumping up charges of
misconduct against officers who challenged institutional abuse or
corruption.
In this case, it was the Police Minister who got involved. He was going to confront the Deputy Commissioner with the charges, until the latter
resigned and saved everyone the trouble.
So you see, politicians do have their role as part of the checks and
balances in a democracy.
On Thu, 15 May 2025 00:04:31 +0100, Pancho wrote:
Oddly, the people who proclaim the great checks and balances afforded by
the judiciary seem to forget the odious decisions made by the judiciary,
as long as the black robes do the 'right' thing for the moment.
A pox on them all.
Wasn't someone supposed to drain the swamp? It is very hard to know what
to do.