Unix's special way of marking login shells goes back to V2 Unix (at least)

Re:Unix's special way of marking login shells goes back to V... by kragen on Sunday December 11, 2022 @08:52AM (#33943161)

you don't need megabytes to allocate your strings dynamically, microsoft basic did it on the altair in 4k

"/bin/sh\0" or "\7\0/bin/sh" is less than 14 bytes, not more, even including a pointer or two

the real issue is that anything you try to allocate dynamically can fail, so you need a failure path, and your failure path needs to reliably free all the other dynamically allocated resources

early unix kind of sucked at handling failures

a fixed-size buffer isn't more efficient but it is simpler

ms-dos used cp/m's filesystem, which had fixed-size filename and ext fields, which i think it copied from rt-11, which i think got them from various pdp-8 systems

fixed-size string buffers make more sense on a word-oriented machine, or arguably in a filesystem, where pointers require some kind of hack

i'd like to blame radix50 but i don't think we can because then the limit would be 9.3 or 6.3 rather than 8.3. there have been some 6.3 filesystems (3 16-bit words per filename with rad50) but cp/m fat (and thus ms-dos) are not among them

[ Parent | on HN ]

Re:Unix's special way of marking login shells goes back to V... by Zardoz84 on Sunday December 11, 2022 @01:25PM (#33945826)

Perhaps I wrong, but FAT and CP/M filesystems, aren't the same. CP/M filesystem never had directories. When the original FAT even predates QDOS as was used by Microsoft on his BASIC in 1977

[ Parent | on HN ]

Re:Unix's special way of marking login shells goes back to V... by kragen on Sunday December 11, 2022 @04:57PM (#33948005)

hmm, i thought fat came from cp/m, not basic-80, but it looks like i was wrong about that

thanks for the correction

https://www.informit.com/articles/article.aspx?p=25878&seqNu...

fat didn't have subdirectories in qdos or ms-dos pre-2 either

[ Parent | on HN ]

Re:Unix's special way of marking login shells goes back to V... by tinus_hn on Sunday December 11, 2022 @12:11PM (#33945025)

A great and easy idea, as long as you never need to release anything. Otherwise you end up with holes in your memory and you need to do compaction, and reserve the memory you need to be able to do that.

[ Parent | on HN ]

Re:Unix's special way of marking login shells goes back to V... by kragen on Sunday December 11, 2022 @04:59PM (#33948024)

or you can just have memory fragmentation

compaction doesn't require a lot of memory but it's slow and intrusive; it has to know where all your buffer pointers are

[ Parent | on HN ]

Re:Unix's special way of marking login shells goes back to V... by tinus_hn on Sunday December 11, 2022 @05:31PM (#33948298)

Obviously permanently wasting memory on fragmentation is not an option on a device that typically has 24kb memory. Especially not just so you can specify long filenames for the shell, when the filesystem doesn’t even support those filenames.

[ Parent | on HN ]

Re:Unix's special way of marking login shells goes back to V... by kragen on Monday December 12, 2022 @03:05PM (#33959478)

the alternative they chose was to permanently waste memory on fixed-size struct fields, so i guess it was actually an option

malloc on the pdp-11 never compacted of course

the filesystem supported 14 characters for the basename, but evidently we're talking about code with a 14-character limit on the pathname, not the basename

[ Parent | on HN ]

Re:Unix's special way of marking login shells goes back to V... by tinus_hn on Tuesday December 13, 2022 @08:23AM (#33968473)

You don’t need compaction to reuse fixed size structures. I presume their priorities were with creating a working system, not one that answers to the ‘requirements’ of 50 years into the future.

[ Parent | on HN ]

Re:Unix's special way of marking login shells goes back to V... by kragen on Thursday December 15, 2022 @01:59AM (#33996210)

you don't need compaction to reuse heap-allocated memory either

wasted memory due to heap fragmentation is very similar to wasted memory due to slack space in fixed-size structure fields

[ Parent | on HN ]