some problems for an introductory python test

[Grant Edwards]

On 2021-08-12, Hope Rouselle <hrouselle at jevedi.com> wrote:

>> OS/2 had all kinds of amazing features (for its time). [...] Plus,
>> it had this fancy concept of "extended attributes"; on older
>> systems (like MS-DOS's "FAT" family), a file might be Read-Only,
>> Hidden, a System file, or needing to be Archived, and that was it -
>> but on HPFS, you could attach arbitrary data like "File type:
>> DeScribe Word Processor" or "Double click action: Run
>> CASMake.cmd". This allowed the GUI to store all kinds of
>> information *on the file itself* instead of needing hidden files
>> (or, in Windows' case, the registry) to track that kind of thing.
>
> Yeah, that's kinda nice.  Isn't that a UNIX design?  A file is a
> sequence of bytes?  Users decide what to put in them?

I think what he's talking about is allowing the user to attach
arbitrary _metadata_ to the file -- metadata that exists separately
and independently from the normal data that's just a "sequence of
bytes". IOW, something similar to the "resource fork" that MacOS used
to have. https://en.wikipedia.org/wiki/Resource_fork

> So OS/2 was taking advantage of that to integrate it well with the
> system.  Windows was doing the same, but integrating the system with
> files in odd ways --- such as a registry record to inform the system
> which programs open which files?  (That does sound more messy.)

Windows never had filesystems that supported metadata like OS/2 and
MacOS did. The registry was an ugly hack that attempted (very poorly)
to make up for that lack of metadata.

> UNIX's execve() is able to read the first line of an executable and
> invoke its interpreter.  I guess OS/2 was doing precisely that in a
> different way?

No, that's not at all the same thing. The #! line is part of the
normal file data. It's part of the 'sequence of bytes'. Metadata
maintained by Unix filesystems comprises a very limited and
pre-defined set of attributes present in the inode.

--
Grant