Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.os.linux.misc > #87295 > unrolled thread
| Started by | TheLastSysop <thelastsysop@dev.null> |
|---|---|
| First post | 2026-05-30 22:28 +0000 |
| Last post | 2026-06-07 01:33 -0400 |
| Articles | 20 on this page of 119 — 15 participants |
Back to article view | Back to comp.os.linux.misc
The boring Linux habit that saves machines TheLastSysop <thelastsysop@dev.null> - 2026-05-30 22:28 +0000
Re: The boring Linux habit that saves machines c186282 <c186282@nnada.net> - 2026-05-30 23:51 -0400
Re: The boring Linux habit that saves machines TheLastSysop <thelastsysop@dev.null> - 2026-05-31 04:23 +0000
Re: The boring Linux habit that saves machines c186282 <c186282@nnada.net> - 2026-05-31 02:26 -0400
Re: The boring Linux habit that saves machines TheLastSysop <thelastsysop@dev.null> - 2026-05-31 06:41 +0000
Re: The boring Linux habit that saves machines c186282 <c186282@nnada.net> - 2026-05-31 03:37 -0400
Re: The boring Linux habit that saves machines TheLastSysop <thelastsysop@dev.null> - 2026-05-31 07:46 +0000
Re: The boring Linux habit that saves machines Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-06 08:55 +0000
Re: The boring Linux habit that saves machines "Carlos E.R." <robin_listas@es.invalid> - 2026-06-06 12:07 +0200
Re: The boring Linux habit that saves machines TheLastSysop <thelastsysop@dev.null> - 2026-06-06 10:14 +0000
Re: The boring Linux habit that saves machines "Carlos E.R." <robin_listas@es.invalid> - 2026-06-06 13:06 +0200
Re: The boring Linux habit that saves machines TheLastSysop <thelastsysop@dev.null> - 2026-06-06 11:12 +0000
Re: The boring Linux habit that saves machines Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-07 02:45 +0000
Re: The boring Linux habit that saves machines c186282 <c186282@nnada.net> - 2026-06-07 05:13 -0400
Re: The boring Linux habit that saves machines Rich <rich@example.invalid> - 2026-06-06 18:30 +0000
Re: The boring Linux habit that saves machines "Carlos E.R." <robin_listas@es.invalid> - 2026-06-06 20:49 +0200
Re: The boring Linux habit that saves machines c186282 <c186282@nnada.net> - 2026-06-07 02:00 -0400
Re: The boring Linux habit that saves machines Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-06 09:07 +0000
Re: The boring Linux habit that saves machines c186282 <c186282@nnada.net> - 2026-06-07 02:11 -0400
Re: The boring Linux habit that saves machines Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-06 09:10 +0000
Re: The boring Linux habit that saves machines c186282 <c186282@nnada.net> - 2026-06-07 02:15 -0400
Re: The boring Linux habit that saves machines Anssi Saari <anssi.saari@usenet.mail.kapsi.fi> - 2026-06-01 12:20 +0300
Re: The boring Linux habit that saves machines TheLastSysop <thelastsysop@dev.null> - 2026-06-01 09:38 +0000
Re: The boring Linux habit that saves machines c186282 <c186282@nnada.net> - 2026-06-02 02:20 -0400
Re: The boring Linux habit that saves machines TheLastSysop <thelastsysop@dev.null> - 2026-06-02 11:08 +0000
Re: The boring Linux habit that saves machines c186282 <c186282@nnada.net> - 2026-06-02 23:58 -0400
Re: The boring Linux habit that saves machines TheLastSysop <thelastsysop@dev.null> - 2026-06-04 11:47 +0000
Re: The boring Linux habit that saves machines c186282 <c186282@nnada.net> - 2026-06-04 11:57 -0400
Re: The boring Linux habit that saves machines TheLastSysop <thelastsysop@dev.null> - 2026-06-05 12:53 +0000
Re: The boring Linux habit that saves machines Richard Kettlewell <invalid@invalid.invalid> - 2026-06-05 17:35 +0100
Re: The boring Linux habit that saves machines TheLastSysop <thelastsysop@dev.null> - 2026-06-05 16:42 +0000
Re: The boring Linux habit that saves machines c186282 <c186282@nnada.net> - 2026-06-06 00:06 -0400
Re: The boring Linux habit that saves machines Richard Kettlewell <invalid@invalid.invalid> - 2026-06-06 10:35 +0100
Re: The boring Linux habit that saves machines c186282 <c186282@nnada.net> - 2026-06-07 03:35 -0400
Re: The boring Linux habit that saves machines The Natural Philosopher <tnp@invalid.invalid> - 2026-06-07 13:39 +0100
Re: The boring Linux habit that saves machines Richard Kettlewell <invalid@invalid.invalid> - 2026-06-07 14:41 +0100
Re: The boring Linux habit that saves machines c186282 <c186282@nnada.net> - 2026-06-08 00:04 -0400
Re: The boring Linux habit that saves machines The Natural Philosopher <tnp@invalid.invalid> - 2026-06-08 09:34 +0100
Re: The boring Linux habit that saves machines Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2026-06-08 18:08 +0000
Re: The boring Linux habit that saves machines The Natural Philosopher <tnp@invalid.invalid> - 2026-06-08 21:24 +0100
Re: The boring Linux habit that saves machines rbowman <bowman@montana.com> - 2026-06-09 01:46 +0000
Re: The boring Linux habit that saves machines c186282 <c186282@nnada.net> - 2026-06-09 03:09 -0400
Re: The boring Linux habit that saves machines The Natural Philosopher <tnp@invalid.invalid> - 2026-06-09 11:17 +0100
Re: The boring Linux habit that saves machines c186282 <c186282@nnada.net> - 2026-06-09 02:54 -0400
Re: The boring Linux habit that saves machines c186282 <c186282@nnada.net> - 2026-06-09 01:27 -0400
Re: The boring Linux habit that saves machines "Carlos E.R." <robin_listas@es.invalid> - 2026-06-09 10:57 +0200
Re: The boring Linux habit that saves machines Lars Poulsen <lars@beagle-ears.com> - 2026-06-07 08:00 -0700
Re: The boring Linux habit that saves machines Richard Kettlewell <invalid@invalid.invalid> - 2026-06-07 16:35 +0100
Re: The boring Linux habit that saves machines Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-07 23:48 +0000
Re: The boring Linux habit that saves machines Nuno Silva <nunojsilva@invalid.invalid> - 2026-06-08 00:53 +0100
Re: The boring Linux habit that saves machines Richard Kettlewell <invalid@invalid.invalid> - 2026-06-08 08:26 +0100
Re: The boring Linux habit that saves machines c186282 <c186282@nnada.net> - 2026-06-08 23:06 -0400
Re: The boring Linux habit that saves machines c186282 <c186282@nnada.net> - 2026-06-08 00:11 -0400
Re: The boring Linux habit that saves machines The Natural Philosopher <tnp@invalid.invalid> - 2026-06-06 10:39 +0100
Re: The boring Linux habit that saves machines c186282 <c186282@nnada.net> - 2026-06-07 03:44 -0400
Re: The boring Linux habit that saves machines c186282 <c186282@nnada.net> - 2026-06-05 23:55 -0400
Re: The boring Linux habit that saves machines TheLastSysop <thelastsysop@dev.null> - 2026-06-06 09:40 +0000
Re: The boring Linux habit that saves machines Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-07 02:47 +0000
Re: The boring Linux habit that saves machines "Carlos E.R." <robin_listas@es.invalid> - 2026-06-07 13:58 +0200
Re: The boring Linux habit that saves machines Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2026-06-07 20:40 +0000
Re: The boring Linux habit that saves machines Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-07 23:39 +0000
Re: The boring Linux habit that saves machines c186282 <c186282@nnada.net> - 2026-06-07 23:00 -0400
Re: The boring Linux habit that saves machines Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2026-06-08 04:36 +0000
Re: The boring Linux habit that saves machines c186282 <c186282@nnada.net> - 2026-06-08 02:30 -0400
Re: The boring Linux habit that saves machines The Natural Philosopher <tnp@invalid.invalid> - 2026-06-08 09:19 +0100
Re: The boring Linux habit that saves machines c186282 <c186282@nnada.net> - 2026-06-08 23:53 -0400
Re: The boring Linux habit that saves machines rbowman <bowman@montana.com> - 2026-06-08 14:23 +0000
Re: The boring Linux habit that saves machines c186282 <c186282@nnada.net> - 2026-06-09 02:28 -0400
Re: The boring Linux habit that saves machines Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2026-06-08 18:08 +0000
Re: The boring Linux habit that saves machines "Carlos E.R." <robin_listas@es.invalid> - 2026-06-08 22:42 +0200
Re: The boring Linux habit that saves machines Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-09 00:45 +0000
Re: The boring Linux habit that saves machines rbowman <bowman@montana.com> - 2026-06-09 01:44 +0000
Re: The boring Linux habit that saves machines c186282 <c186282@nnada.net> - 2026-06-09 03:08 -0400
Re: The boring Linux habit that saves machines "Carlos E.R." <robin_listas@es.invalid> - 2026-06-09 11:07 +0200
Re: The boring Linux habit that saves machines Nuno Silva <nunojsilva@invalid.invalid> - 2026-06-08 09:54 +0100
Re: The boring Linux habit that saves machines Eric Pozharski <apple.universe@posteo.net> - 2026-06-08 21:46 +0000
Re: The boring Linux habit that saves machines Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-09 04:50 +0000
Re: The boring Linux habit that saves machines c186282 <c186282@nnada.net> - 2026-06-09 03:16 -0400
Re: The boring Linux habit that saves machines Richard Kettlewell <invalid@invalid.invalid> - 2026-06-09 08:49 +0100
Re: The boring Linux habit that saves machines c186282 <c186282@nnada.net> - 2026-06-09 01:48 -0400
Re: The boring Linux habit that saves machines "Carlos E.R." <robin_listas@es.invalid> - 2026-06-09 11:11 +0200
Re: The boring Linux habit that saves machines rbowman <bowman@montana.com> - 2026-06-08 14:12 +0000
Re: The boring Linux habit that saves machines Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2026-06-08 18:08 +0000
Re: The boring Linux habit that saves machines rbowman <bowman@montana.com> - 2026-06-09 01:30 +0000
Re: The boring Linux habit that saves machines "Carlos E.R." <robin_listas@es.invalid> - 2026-06-09 11:15 +0200
Re: The boring Linux habit that saves machines Richard Kettlewell <invalid@invalid.invalid> - 2026-06-07 14:30 +0100
Re: The boring Linux habit that saves machines c186282 <c186282@nnada.net> - 2026-06-07 23:38 -0400
Re: The boring Linux habit that saves machines The Natural Philosopher <tnp@invalid.invalid> - 2026-06-08 09:22 +0100
Re: The boring Linux habit that saves machines c186282 <c186282@nnada.net> - 2026-06-09 00:28 -0400
Re: The boring Linux habit that saves machines c186282 <c186282@nnada.net> - 2026-06-07 04:03 -0400
Re: The boring Linux habit that saves machines Rich <rich@example.invalid> - 2026-06-06 18:42 +0000
Re: The boring Linux habit that saves machines Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-06 08:53 +0000
Re: The boring Linux habit that saves machines c186282 <c186282@nnada.net> - 2026-06-07 01:53 -0400
Re: The boring Linux habit that saves machines Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-06 08:52 +0000
Re: The boring Linux habit that saves machines c186282 <c186282@nnada.net> - 2026-06-07 01:41 -0400
Re: The boring Linux habit that saves machines Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-06 06:41 +0000
Re: The boring Linux habit that saves machines c186282 <c186282@nnada.net> - 2026-06-06 03:07 -0400
Re: The boring Linux habit that saves machines "Carlos E.R." <robin_listas@es.invalid> - 2026-06-06 13:28 +0200
Re: The boring Linux habit that saves machines rbowman <bowman@montana.com> - 2026-06-06 19:16 +0000
Re: The boring Linux habit that saves machines c186282 <c186282@nnada.net> - 2026-06-07 05:18 -0400
Re: The boring Linux habit that saves machines rbowman <bowman@montana.com> - 2026-06-07 18:59 +0000
Re: The boring Linux habit that saves machines TheLastSysop <thelastsysop@dev.null> - 2026-06-06 09:40 +0000
Re: The boring Linux habit that saves machines Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-07 02:51 +0000
Re: The boring Linux habit that saves machines c186282 <c186282@nnada.net> - 2026-06-07 04:56 -0400
Re: The boring Linux habit that saves machines "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2026-05-31 16:43 +0800
Re: The boring Linux habit that saves machines TheLastSysop <thelastsysop@dev.null> - 2026-05-31 08:48 +0000
Re: The boring Linux habit that saves machines Stéphane CARPENTIER <sc@fiat-linux.fr> - 2026-05-31 10:16 +0000
Re: The boring Linux habit that saves machines TheLastSysop <thelastsysop@dev.null> - 2026-05-31 10:22 +0000
Re: The boring Linux habit that saves machines Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-06 06:38 +0000
Re: The boring Linux habit that saves machines c186282 <c186282@nnada.net> - 2026-06-06 03:04 -0400
Re: The boring Linux habit that saves machines "Carlos E.R." <robin_listas@es.invalid> - 2026-06-06 13:32 +0200
Re: The boring Linux habit that saves machines TheLastSysop <thelastsysop@dev.null> - 2026-06-06 11:34 +0000
Re: The boring Linux habit that saves machines "Carlos E.R." <robin_listas@es.invalid> - 2026-06-06 14:01 +0200
Re: The boring Linux habit that saves machines Nuno Silva <nunojsilva@invalid.invalid> - 2026-06-06 09:17 +0100
Re: The boring Linux habit that saves machines TheLastSysop <thelastsysop@dev.null> - 2026-06-06 09:40 +0000
Re: The boring Linux habit that saves machines Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-07 02:57 +0000
Re: The boring Linux habit that saves machines Nuno Silva <nunojsilva@invalid.invalid> - 2026-06-07 16:11 +0100
Re: The boring Linux habit that saves machines c186282 <c186282@nnada.net> - 2026-06-07 04:18 -0400
Re: The boring Linux habit that saves machines c186282 <c186282@nnada.net> - 2026-06-07 01:33 -0400
Page 4 of 6 — ← Prev page 1 2 3 [4] 5 6 Next page →
| From | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2026-06-07 23:39 +0000 |
| Message-ID | <1104vg4$2rlf4$7@dont-email.me> |
| In reply to | #87662 |
On Sun, 07 Jun 2026 20:40:08 GMT, Charlie Gibbs wrote: > On 2026-06-07 04:47, Lawrence D’Oliveiro wrote: >> >> I must admit, I could probably live with forbidding newlines in >> file/directory names. Why not reserve one little character, just to >> make life that little bit easier for shell script writers? ;) > > ... > > It generated all sorts of invalid characters - starting with colon - > then worked its way up to 0xFF, wrapped around to 0x00, and carried > on. Cleaning up that mess was a pain in the ass. Now, you see, I wouldn’t go that far. On a POSIX system, those characters would not be technically “invalid”, because then the OS would have failed the filesystem operation with an error instead of permitting the creation of such filenames. And if they’re valid filenames, it *is* possible to deal with them in a POSIX shell. I wouldn’t call it “a pain in the ass”, it just takes some careful programming. > I don't mind forbidding a number of characters in file names: > carriage return, line feed, colon, slash (both forward and > back), and NUL to name a few. Whenever I need a “/” in a file/directory name, I substitute the Unicode lookalike ”∕” instead. Works just as well visually, but causes no problems with the OS or scripts. ;)
[toc] | [prev] | [next] | [standalone]
| From | c186282 <c186282@nnada.net> |
|---|---|
| Date | 2026-06-07 23:00 -0400 |
| Message-ID | <SCudnXWn6J_Srbv3nZ2dnZfqn_ednZ2d@giganews.com> |
| In reply to | #87662 |
On 6/7/26 16:40, Charlie Gibbs wrote: > On 2026-06-07, Carlos E.R. <robin_listas@es.invalid> wrote: > >> On 2026-06-07 04:47, Lawrence D’Oliveiro wrote: >> >>> On Sat, 06 Jun 2026 09:40:20 GMT, TheLastSysop wrote: >>> >>>> Most backup bugs in this area are not the weird Unicode character >>>> itself; they are the one forgotten script that splits on whitespace >>>> or treats a newline in a filename as a record separator. >>> >>> I must admit, I could probably live with forbidding newlines in >>> file/directory names. Why not reserve one little character, just to >>> make life that little bit easier for shell script writers? ;) >> >> I have never seen them in real life. I would make a firing offence to >> create such files. Biz doesn't work without employees :-) Long nasty narrative filenames with lots of punctuation became our norm and nobody would stop doing it. A 'human nature' issue alas. Yes, 8+3 ALL CAPS is indeed easy to deal with, but at this point, just forget it. Got to adapt yer code to the humans. > In the early '90s we ported a bunch of COBOL programs from our > Univac mainframe to a Unix box. Micro Focus COBOL was generally > a pretty decent compiler, and made the port fairly easy. However, > we discovered a couple of nasty things in its implementation of > the SORT verb. First of all, the work files it created on disk > defaulted to being ridiculously small - a few K at most. This > paved the way for the really nasty misfeature: the creation of > work file names. The data we were sorting was large enough that > it generated something like 12,000 little work files. The names > of these files contained a 3-digit sequence number. When it > passed 999, the overflow caused the high-order digit to continue > to work its way up through the ASCII table - and beyond. It > generated all sorts of invalid characters - starting with colon - > then worked its way up to 0xFF, wrapped around to 0x00, and > carried on. Cleaning up that mess was a pain in the ass. DID briefly work with Micro Focus ... also translating a number of old apps to more 'modern' langs. Sounds like yer programs proceeded 'logically' - until there got to be TOO many files. Sometimes writers highball expectations, sometimes the opposite. "More than 1000 files ? Who'd DO that ???" Want fun - try moving dozens of old FORTRAN stat apps to GWBASIC ... and HAND-CODING the math-coprocessor instructions as DATA statements. Ah, the Good Old Days ! :-) No, they couldn't afford a good FORTRAN compiler at the time ..... > I don't mind forbidding a number of characters in file names: > carriage return, line feed, colon, slash (both forward and > back), and NUL to name a few. Runs of multiple spaces, or a > space at the beginning or the end of a file name, is harder > to enforce, but it's just asking for trouble and I do my > best to avoid all of them. > > I have no objection to UTF-8 characters, though. Don't love 'em. By the time 8+3 became 12+3 became 128/256/1024 then naming constraints disappeared. Alas, esp M$, they TOTALLY disappeared. Several functionaries tended to use the entire first sentence of their docs as the file name - cut-n-paste ! :-) Yes, that sometimes included mystery "invisible" characters from the word processor. UTF ... ever tried to FIND those neat old angle/block/etc char sets that came with the old IBM-PCs, ASCII 129+ ? Made for NICE terminal forms really easy. Anyway, you'll be much much more successful (if overworked) making your code cope with the users instead of expecting the opposite to happen. One of you, LOTS of them ... and some have labor unions .......
[toc] | [prev] | [next] | [standalone]
| From | Charlie Gibbs <cgibbs@kltpzyxm.invalid> |
|---|---|
| Date | 2026-06-08 04:36 +0000 |
| Message-ID | <nFrVR.31495$4Y2.20574@fx43.iad> |
| In reply to | #87673 |
On 2026-06-08, c186282 <c186282@nnada.net> wrote: > On 6/7/26 16:40, Charlie Gibbs wrote: > > Sounds like yer programs proceeded 'logically' - until > there got to be TOO many files. Sometimes writers highball > expectations, sometimes the opposite. "More than 1000 files ? > Who'd DO that ???" The top entry in my list of Famous Last Words is: "Oh, don't worry about that; it'll never happen." I learned early on that "never" is usually about six months. But defaulting the work file size to a ridiculously small value is just begging for bad things to happen. >> I have no objection to UTF-8 characters, though. > > Don't love 'em. There are some places where I'd avoid them, because they'd be too easily abused, erroneously transcribed, etc. But for my own use (e.g. a music score by Antonín Dvořák), anything goes. > By the time 8+3 became 12+3 became 128/256/1024 then > naming constraints disappeared. Alas, esp M$, they > TOTALLY disappeared. Ah yes, good old MICROS~1.. > Several functionaries tended to > use the entire first sentence of their docs as the > file name - cut-n-paste ! :-) I once read in a description of the early Mac that said "you could write a letter to Grandma in the file name". > Anyway, you'll be much much more successful (if overworked) > making your code cope with the users instead of expecting > the opposite to happen. One of you, LOTS of them ... and > some have labor unions ....... Still, I like to get in little digs like, "You know, if you had kept your file names simpler you might not have had to call me. Again." And so far, I've gotten away with using ISO 8601 dates everywhere. :-) -- /~\ Charlie Gibbs | No artificial \ / <cgibbs@kltpzyxm.invalid> | intelligence was X I'm really at ac.dekanfrus | used in the creation / \ if you read it the right way. | of this post.
[toc] | [prev] | [next] | [standalone]
| From | c186282 <c186282@nnada.net> |
|---|---|
| Date | 2026-06-08 02:30 -0400 |
| Message-ID | <SCudnXOn6J8J_Lv3nZ2dnZfqn_ednZ2d@giganews.com> |
| In reply to | #87680 |
On 6/8/26 00:36, Charlie Gibbs wrote: > On 2026-06-08, c186282 <c186282@nnada.net> wrote: > >> On 6/7/26 16:40, Charlie Gibbs wrote: >> >> Sounds like yer programs proceeded 'logically' - until >> there got to be TOO many files. Sometimes writers highball >> expectations, sometimes the opposite. "More than 1000 files ? >> Who'd DO that ???" > > The top entry in my list of Famous Last Words is: > "Oh, don't worry about that; it'll never happen." > I learned early on that "never" is usually about six months. Heh heh ! Damned right !!! > But defaulting the work file size to a ridiculously small value > is just begging for bad things to happen. Well ... remember how TINY the Computing Environment tended to be. Assumptions were made. CP/M, DOS, even some other systems ... they just ASSUMED usage would easily fall into line with the system limits. Only loons would have over 10,000 database records, over 100 text processing files ! Wouldn't fit in 64k anyhow !!! >>> I have no objection to UTF-8 characters, though. >> >> Don't love 'em. > > There are some places where I'd avoid them, because they'd > be too easily abused, erroneously transcribed, etc. But for > my own use (e.g. a music score by Antonín Dvořák), anything goes. > >> By the time 8+3 became 12+3 became 128/256/1024 then >> naming constraints disappeared. Alas, esp M$, they >> TOTALLY disappeared. > > Ah yes, good old MICROS~1.. > >> Several functionaries tended to >> use the entire first sentence of their docs as the >> file name - cut-n-paste ! :-) > > I once read in a description of the early Mac that said > "you could write a letter to Grandma in the file name". Mac was a bit "ahead" in that respect - I seem to remember Amiga could do long file names too. But anything can be taken to a ridiculous extreme. Now everyone is USED to the ridiculous extremes. So ... we've gotta code AROUND it. >> Anyway, you'll be much much more successful (if overworked) >> making your code cope with the users instead of expecting >> the opposite to happen. One of you, LOTS of them ... and >> some have labor unions ....... > > Still, I like to get in little digs like, "You know, if you had > kept your file names simpler you might not have had to call me. > Again." And so far, I've gotten away with using ISO 8601 dates > everywhere. :-) Well ... think of "again" as "Job Security" :-) Always a ray of sunshine somewhere. Anyway, retired ... it's Someone Else's Problem now.
[toc] | [prev] | [next] | [standalone]
| From | The Natural Philosopher <tnp@invalid.invalid> |
|---|---|
| Date | 2026-06-08 09:19 +0100 |
| Message-ID | <1105ttl$32iur$3@dont-email.me> |
| In reply to | #87684 |
On 08/06/2026 07:30, c186282 wrote: > Well ... remember how TINY the Computing Environment > tended to be. Assumptions were made. CP/M, DOS, even > some other systems ... they just ASSUMED usage would > easily fall into line with the system limits. Only > loons would have over 10,000 database records, over > 100 text processing files ! Wouldn't fit in 64k > anyhow !!! The only assumption they made was that coders would not be stupid enough to write code that exceeded their limits. They anticipated writing tools for engineers, not abstractions for computer scientists. -- The New Left are the people they warned you about.
[toc] | [prev] | [next] | [standalone]
| From | c186282 <c186282@nnada.net> |
|---|---|
| Date | 2026-06-08 23:53 -0400 |
| Message-ID | <zOCcnVhzd4jKE7r3nZ2dnZfqn_ednZ2d@giganews.com> |
| In reply to | #87688 |
On 6/8/26 04:19, The Natural Philosopher wrote: > On 08/06/2026 07:30, c186282 wrote: >> Well ... remember how TINY the Computing Environment >> tended to be. Assumptions were made. CP/M, DOS, even >> some other systems ... they just ASSUMED usage would >> easily fall into line with the system limits. Only >> loons would have over 10,000 database records, over >> 100 text processing files ! Wouldn't fit in 64k >> anyhow !!! > > The only assumption they made was that coders would not be stupid enough > to write code that exceeded their limits. > They anticipated writing tools for engineers, not abstractions for > computer scientists. Think back to the great early-DOS apps. The max file sizes, record numbers, were often very limited. They just made ASSUMPTIONS based on the tech of the moment. Within just a few years they were off by orders of magnitude - but WOULD sell you the New And Improved version, of course :-) I remember stuffing big ISA boards with masses of little RAM chips - trying to be VERY careful not to bend the pins. Even thus a few WOULD be bad. Fun ! "Extended" memory was NEW - but everyone WANTED it. I remember our first, GIGANTIC, 10mb hard disk - Rodime. Full-height and seemed to weigh near 10 pounds. But WOW ! Earned a weird rep back then, the guy who programmed with a Buck Knife ... always needed one to align and insert and pry-out odd chips :-) Before that, mag-tape units. Slower,n shit from a constipated yak. Overlays were SUCH fun to code ... Can still remember when early Turbo Pascal offered easy overlays - DOS 2.x & CP/M. Used them quite a bit. "Computing" just grew a LOT LOT LOT faster than anybody imagined, kind of the fabled 'exponential curve' for awhile. In a few years our DB had ten YEARS worth of detailed records in accounts - old and new stuff. The indexing files alone were WAY over 64kb. TODAY ... "large" is kind of assumed ... but sure as hell wasn't ALWAYS that way.
[toc] | [prev] | [next] | [standalone]
| From | rbowman <bowman@montana.com> |
|---|---|
| Date | 2026-06-08 14:23 +0000 |
| Message-ID | <n8o1inFqrflU8@mid.individual.net> |
| In reply to | #87684 |
On Mon, 8 Jun 2026 02:30:35 -0400, c186282 wrote: > Well ... remember how TINY the Computing Environment tended to be. > Assumptions were made. CP/M, DOS, even some other systems ... they > just ASSUMED usage would easily fall into line with the system > limits. Only loons would have over 10,000 database records, over 100 > text processing files ! Wouldn't fit in 64k anyhow !!! The DB2 database had two tables for person and vehicle records that were meant to be used for looking up recent activity for Georgie Gangster and so forth. In theory older records were irrelevant and would be purged, but there wasn't any mechanism to do so. When the client complained about the system being slow I found there were well over a million records and an index had never been se up. The whole mess was several gigabytes. This was around 2001 and I had a hell of a time finding an AIX machine in house with that much free space to restore it for testing. Flash back to my first hard drive on an AT clone. I can't remember if it was 5 or 10 MB but I had no idea why you would ever need that much storage.
[toc] | [prev] | [next] | [standalone]
| From | c186282 <c186282@nnada.net> |
|---|---|
| Date | 2026-06-09 02:28 -0400 |
| Message-ID | <zOCcnVVzd4gVL7r3nZ2dnZfqn_ednZ2d@giganews.com> |
| In reply to | #87695 |
On 6/8/26 10:23, rbowman wrote: > On Mon, 8 Jun 2026 02:30:35 -0400, c186282 wrote: > >> Well ... remember how TINY the Computing Environment tended to be. >> Assumptions were made. CP/M, DOS, even some other systems ... they >> just ASSUMED usage would easily fall into line with the system >> limits. Only loons would have over 10,000 database records, over 100 >> text processing files ! Wouldn't fit in 64k anyhow !!! > > The DB2 database had two tables for person and vehicle records that were > meant to be used for looking up recent activity for Georgie Gangster and > so forth. In theory older records were irrelevant and would be purged, but > there wasn't any mechanism to do so. When the client complained about the > system being slow I found there were well over a million records and an > index had never been se up. That DB2 was "ok", FOR IT'S TIME. But again ... built initially for a 64k/floppy environment. Same with all the spreadsheets and word processors and such. Computing power just built SO fast ... most writers were always well behind the curve. > The whole mess was several gigabytes. This was around 2001 and I had a > hell of a time finding an AIX machine in house with that much free space > to restore it for testing. At some point my org switched to "Revelation/AREV". This was based on PICK-OS. It could handle BIG stuff for the most part (except really huge sorts). We put massive numbers of records into that. DO still like the 'multi-value' record format, wrote libs for several langs emulating that. > Flash back to my first hard drive on an AT clone. I can't remember if it > was 5 or 10 MB but I had no idea why you would ever need that much > storage. Ours was 10mb ... like $3000 early-80s dollars as I remember. Rodime, full-height, MFM, custom card, HEAVY !!! The asst director spent a whole weekend trying to get it to boot. I came in on Monday - and just gave it about 90 seconds and it worked. The boss wasn't patient enough to wait 90 seconds before he'd reboot :-)
[toc] | [prev] | [next] | [standalone]
| From | Charlie Gibbs <cgibbs@kltpzyxm.invalid> |
|---|---|
| Date | 2026-06-08 18:08 +0000 |
| Message-ID | <dyDVR.24698$Mm3.7319@fx33.iad> |
| In reply to | #87684 |
On 2026-06-08, c186282 <c186282@nnada.net> wrote: > On 6/8/26 00:36, Charlie Gibbs wrote: > >> On 2026-06-08, c186282 <c186282@nnada.net> wrote: >> >>> On 6/7/26 16:40, Charlie Gibbs wrote: >>> >>> Sounds like yer programs proceeded 'logically' - until >>> there got to be TOO many files. Sometimes writers highball >>> expectations, sometimes the opposite. "More than 1000 files ? >>> Who'd DO that ???" >> >> The top entry in my list of Famous Last Words is: >> "Oh, don't worry about that; it'll never happen." >> I learned early on that "never" is usually about six months. > > Heh heh ! Damned right !!! > >> But defaulting the work file size to a ridiculously small value >> is just begging for bad things to happen. > > Well ... remember how TINY the Computing Environment > tended to be. Assumptions were made. CP/M, DOS, even > some other systems ... they just ASSUMED usage would > easily fall into line with the system limits. Only > loons would have over 10,000 database records, over > 100 text processing files ! Wouldn't fit in 64k > anyhow !!! Yes, yes, 640K ought to be enough for anyone. But this was a Unix box - I was expecting a bit more common sense. >>>> I have no objection to UTF-8 characters, though. >>> >>> Don't love 'em. >> >> There are some places where I'd avoid them, because they'd >> be too easily abused, erroneously transcribed, etc. But for >> my own use (e.g. a music score by Antonín Dvořák), anything goes. >> >>> By the time 8+3 became 12+3 became 128/256/1024 then >>> naming constraints disappeared. Alas, esp M$, they >>> TOTALLY disappeared. >> >> Ah yes, good old MICROS~1.. >> >>> Several functionaries tended to >>> use the entire first sentence of their docs as the >>> file name - cut-n-paste ! :-) >> >> I once read in a description of the early Mac that said >> "you could write a letter to Grandma in the file name". > > Mac was a bit "ahead" in that respect - I seem to > remember Amiga could do long file names too. Thirty characters. It seemed long at the time, though. > But anything can be taken to a ridiculous extreme. > > Now everyone is USED to the ridiculous extremes. > > So ... we've gotta code AROUND it. Yup. But some of it gets old in a hurry. Like that stupid hex 1A character which MS-DOS inherited from CP/M even though it's not necessary in any file system that stores file sizes to the byte rather than as a number of sectors. Or the COPY command's refusal to copy zero-length files (that one took down a beta site and ate a month's worth of data, so I reworked my batch files to not depend on the COPY command). >>> Anyway, you'll be much much more successful (if overworked) >>> making your code cope with the users instead of expecting >>> the opposite to happen. One of you, LOTS of them ... and >>> some have labor unions ....... >> >> Still, I like to get in little digs like, "You know, if you had >> kept your file names simpler you might not have had to call me. >> Again." And so far, I've gotten away with using ISO 8601 dates >> everywhere. :-) > > Well ... think of "again" as "Job Security" :-) > > Always a ray of sunshine somewhere. > > Anyway, retired ... it's Someone Else's Problem now. Remember the SEP field in _The Hitchhiker's Guide to the Galaxy_? It made Slartibartfast's spaceship invisible by making it look like Somebody Else's Problem. -- /~\ Charlie Gibbs | No artificial \ / <cgibbs@kltpzyxm.invalid> | intelligence was X I'm really at ac.dekanfrus | used in the creation / \ if you read it the right way. | of this post.
[toc] | [prev] | [next] | [standalone]
| From | "Carlos E.R." <robin_listas@es.invalid> |
|---|---|
| Date | 2026-06-08 22:42 +0200 |
| Message-ID | <b2mjfmxes1.ln2@Telcontar.valinor> |
| In reply to | #87700 |
On 2026-06-08 20:08, Charlie Gibbs wrote: > On 2026-06-08, c186282 <c186282@nnada.net> wrote: > >> On 6/8/26 00:36, Charlie Gibbs wrote: >> >>> On 2026-06-08, c186282 <c186282@nnada.net> wrote: > Thirty characters. It seemed long at the time, though. > >> But anything can be taken to a ridiculous extreme. >> >> Now everyone is USED to the ridiculous extremes. >> >> So ... we've gotta code AROUND it. > > Yup. But some of it gets old in a hurry. Like that stupid > hex 1A character which MS-DOS inherited from CP/M even though > it's not necessary in any file system that stores file sizes > to the byte rather than as a number of sectors. Or the COPY > command's refusal to copy zero-length files (that one took > down a beta site and ate a month's worth of data, so I reworked > my batch files to not depend on the COPY command). It had its uses. For example create a data file, which starts with some descriptive text, including the name of the program to open the file with, and the <EOF>, followed by the actual data. The user would simply "type data.dat" and the instructions would print nicely on the screen. -- Cheers, Carlos. ES🇪🇸, EU🇪🇺;
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2026-06-09 00:45 +0000 |
| Message-ID | <1107nmj$3k6ea$7@dont-email.me> |
| In reply to | #87700 |
On Mon, 08 Jun 2026 18:08:09 GMT, Charlie Gibbs wrote: > Thirty characters. It seemed long at the time, though. The original Mac shipped in 1984 with a filesystem that allowed 63-character filenames. There was no folder hierarchy: the “folders” you saw on the screen were purely a figment of the Finder’s imagination. Then, when Apple introduced a hard drive and double-sided floppies for the Mac in 1986, that also came with a new filesystem that now had real folders ... and a 31-character file/directory name limit. Why? > Like that stupid hex 1A character which MS-DOS inherited from CP/M > even though it's not necessary in any file system that stores file > sizes to the byte rather than as a number of sectors. I imagine it’s because MS-DOS 1.x, like CP/M, only kept track of file allocations in whole sectors. In MS-DOS 2.x, they started trying to copy a few Unix features, like doing file I/O buffering in the OS instead of forcing user programs to worry about it. Unfortunately, building such things on top of a clunky foundation inherited from the 8-bit era was not such a clever thing to do. And Windows users are still paying the price today.
[toc] | [prev] | [next] | [standalone]
| From | rbowman <bowman@montana.com> |
|---|---|
| Date | 2026-06-09 01:44 +0000 |
| Message-ID | <n8p9f7F8q2vU5@mid.individual.net> |
| In reply to | #87700 |
On Mon, 08 Jun 2026 18:08:09 GMT, Charlie Gibbs wrote: > Yes, yes, 640K ought to be enough for anyone. > But this was a Unix box - I was expecting a bit more common sense. Ah, the good old days when you linked VC++ with 5 different libraries depending, tiny, small, medium, large, frigging huge.
[toc] | [prev] | [next] | [standalone]
| From | c186282 <c186282@nnada.net> |
|---|---|
| Date | 2026-06-09 03:08 -0400 |
| Message-ID | <zOCcnVZzd4iVIbr3nZ2dnZfqn_ednZ2d@giganews.com> |
| In reply to | #87708 |
On 6/8/26 21:44, rbowman wrote: > On Mon, 08 Jun 2026 18:08:09 GMT, Charlie Gibbs wrote: > >> Yes, yes, 640K ought to be enough for anyone. >> But this was a Unix box - I was expecting a bit more common sense. > > Ah, the good old days when you linked VC++ with 5 different libraries > depending, tiny, small, medium, large, frigging huge. Heh ... we DID try the lower-end SCO UNIX on our new 'AT's. Alas it was both Too Expensive and Too Slow to really be useful. Not all that much software either. But it WAS interesting ... part of why I went to Linux as soon as possible. DOS, soon Win, had much nicer software.
[toc] | [prev] | [next] | [standalone]
| From | "Carlos E.R." <robin_listas@es.invalid> |
|---|---|
| Date | 2026-06-09 11:07 +0200 |
| Message-ID | <4n1lfmxelh.ln2@Telcontar.valinor> |
| In reply to | #87726 |
On 2026-06-09 09:08, c186282 wrote: > On 6/8/26 21:44, rbowman wrote: >> On Mon, 08 Jun 2026 18:08:09 GMT, Charlie Gibbs wrote: >> >>> Yes, yes, 640K ought to be enough for anyone. >>> But this was a Unix box - I was expecting a bit more common sense. >> >> Ah, the good old days when you linked VC++ with 5 different libraries >> depending, tiny, small, medium, large, frigging huge. > > Heh ... we DID try the lower-end SCO UNIX on > our new 'AT's. Alas it was both Too Expensive > and Too Slow to really be useful. Not all that > much software either. > > But it WAS interesting ... part of why I went > to Linux as soon as possible. > > DOS, soon Win, had much nicer software. I find dos software nicer than Linux software. Editors, for instance. When I started on Linux, I was surprised that ctrl-arrow would not move a word to the left/right, for example. Tons of MsDOS text software that had menus and mouse support. Linux in 1998 felt old. -- Cheers, Carlos. ES🇪🇸, EU🇪🇺;
[toc] | [prev] | [next] | [standalone]
| From | Nuno Silva <nunojsilva@invalid.invalid> |
|---|---|
| Date | 2026-06-08 09:54 +0100 |
| Message-ID | <1105vvm$32n5j$3@dont-email.me> |
| In reply to | #87680 |
On 2026-06-08, Charlie Gibbs wrote: > On 2026-06-08, c186282 <c186282@nnada.net> wrote: > >> By the time 8+3 became 12+3 became 128/256/1024 then naming >> constraints disappeared. Alas, esp M$, they TOTALLY disappeared. > > Ah yes, good old MICROS~1.. I eagerly anticipate the day Microsoft is ordered to split up following some antitrust ruling, if only because then one could propose the split-up parts be named MICROS~1,MICROS~2,...,MICROS~N. >> Several functionaries tended to use the entire first sentence of >> their docs as the file name - cut-n-paste ! :-) > > I once read in a description of the early Mac that said > "you could write a letter to Grandma in the file name". Any chance this is automated behaviour from the document editor? I seem to recall Word doing something like setting the Title or Subject in metadata to the initial text. But memory may be playing tricks &c.; no WINWORD here so I can't test right now. -- Nuno Silva
[toc] | [prev] | [next] | [standalone]
| From | Eric Pozharski <apple.universe@posteo.net> |
|---|---|
| Date | 2026-06-08 21:46 +0000 |
| Message-ID | <slrn112ee2f.m8j.apple.universe@freight.zombinet> |
| In reply to | #87692 |
with <1105vvm$32n5j$3@dont-email.me> Nuno Silva wrote: > On 2026-06-08, Charlie Gibbs wrote: >> On 2026-06-08, c186282 <c186282@nnada.net> wrote: *SKIP* [ 9 lines 3 levels deep] >>> Several functionaries tended to use the entire first sentence of >>> their docs as the file name - cut-n-paste ! :-) >> I once read in a description of the early Mac that said "you could >> write a letter to Grandma in the file name". > Any chance this is automated behaviour from the document editor? I > seem to recall Word doing something like setting the Title or Subject > in metadata to the initial text. But memory may be playing tricks &c.; > no WINWORD here so I can't test right now. Such endeavor would be hilarious (tricky part, is there WINE on x86_64 that will present i386 environment? but it's probably routine), you will need to go back for WW6.0; can't say anything about WW7.0; WW95 did something else (something like NONAME~1; didn't have to deal with it). My impression was: imagine result of filename generation starting from line consisting of 30 spaces and the word "APPROVED". At the end. -- Torvalds' goal for Linux is very simple: World Domination Stallman's goal for GNU is even simpler: Freedom
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2026-06-09 04:50 +0000 |
| Message-ID | <110862u$3nleh$1@dont-email.me> |
| In reply to | #87707 |
On Mon, 08 Jun 2026 21:46:55 +0000, Eric Pozharski wrote: > My impression was: imagine result of filename generation starting > from line consisting of 30 spaces and the word "APPROVED". At the > end. Only 30? Linux filesystems seem to have standardized on allowing 255 bytes in a file/directory name. Whereas some Windows utilities restrict the entire pathname to that length.
[toc] | [prev] | [next] | [standalone]
| From | c186282 <c186282@nnada.net> |
|---|---|
| Date | 2026-06-09 03:16 -0400 |
| Message-ID | <zOCcnVNzd4hNILr3nZ2dnZfqn_ednZ2d@giganews.com> |
| In reply to | #87718 |
On 6/9/26 00:50, Lawrence D’Oliveiro wrote: > On Mon, 08 Jun 2026 21:46:55 +0000, Eric Pozharski wrote: > >> My impression was: imagine result of filename generation starting >> from line consisting of 30 spaces and the word "APPROVED". At the >> end. > > Only 30? > > Linux filesystems seem to have standardized on allowing 255 bytes in a > file/directory name. > > Whereas some Windows utilities restrict the entire pathname to that > length. Did. NOW seems almost "unlimited" - at least 1024. More space to fuck things up.
[toc] | [prev] | [next] | [standalone]
| From | Richard Kettlewell <invalid@invalid.invalid> |
|---|---|
| Date | 2026-06-09 08:49 +0100 |
| Message-ID | <wwvqzmg9mr6.fsf@LkoBDZeT.terraraq.uk> |
| In reply to | #87718 |
Lawrence D’Oliveiro <ldo@nz.invalid> writes: > Eric Pozharski wrote: > >> My impression was: imagine result of filename generation starting >> from line consisting of 30 spaces and the word "APPROVED". At the >> end. > > Only 30? > > Linux filesystems seem to have standardized on allowing 255 bytes in a > file/directory name. Unless it’s an AF_UNIX socket, in which case you get 108 bytes including a 0 terminator for the whole sun_path. Which from time to time causes practical problems. -- https://www.greenend.org.uk/rjk/
[toc] | [prev] | [next] | [standalone]
| From | c186282 <c186282@nnada.net> |
|---|---|
| Date | 2026-06-09 01:48 -0400 |
| Message-ID | <I_qcncNV2ZW4NLr3nZ2dnZfqn_WdnZ2d@giganews.com> |
| In reply to | #87692 |
On 6/8/26 04:54, Nuno Silva wrote: > On 2026-06-08, Charlie Gibbs wrote: > >> On 2026-06-08, c186282 <c186282@nnada.net> wrote: >> >>> By the time 8+3 became 12+3 became 128/256/1024 then naming >>> constraints disappeared. Alas, esp M$, they TOTALLY disappeared. >> >> Ah yes, good old MICROS~1.. > > I eagerly anticipate the day Microsoft is ordered to split up following > some antitrust ruling, if only because then one could propose the > split-up parts be named MICROS~1,MICROS~2,...,MICROS~N. Bill Gates quickly LEARNED - to GREASE your political reps. All his 'trust' problems then instantly disappeared. That's how realpolitik works ... Machiavelli would totally understand. As for what's become "normal" for M$ ... that's been a very long evolution/devolution. Everybody WANTED long file names, then REALLY long file names, so they GOT it for better or worse. Now for us that have to COPE with that mess ... well .... As said somewhere ... a number of workers just took to copy/paste the first sentence - including 'invisible' chars - from their word processor docs as the file name. Too many of THEM, too few of ME ... had to just COPE. Oh well, "job security" I guess. The New Guys can't program their way out of a wet paper bag ... so they just use/pay-for the wunnerful M$ "solutions" and think that's a-OK. Can't really trash them too much, that's Just How It's Done these days. My gen was bits and bytes, theirs is a different world (that WILL bite 'em bad eventually). But they'll just blame it all on M$ ... butts saved. That's how it works now. Kinda tragic ....... WHEN Vlad/Xi/Kim and friends really GO for it ... global DOOM. They'll try to recruit us Old Guys but, well, just TOO Old now ...... I'll "advise" a bit, for $500 an hour :-)
[toc] | [prev] | [next] | [standalone]
Page 4 of 6 — ← Prev page 1 2 3 [4] 5 6 Next page →
Back to top | Article view | comp.os.linux.misc
csiph-web