some problems for an introductory python test

[Hope Rouselle]

Grant Edwards <grant.b.edwards at gmail.com> writes:

> 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

Got ya.

>> 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.

Take a look at NTFS streams.  Maybe you would consider that as a way to
store metadata in Windows.  Pavel Yosifovich talks about them briefly in
chapter 11, page 555, part 1.  Windows 10 System Programming.  Here's
the first paragraph:

--8<---------------cut here---------------start------------->8---
The NTFS filesystem supports /file streams/, which are essentially files
within a file.  Normally, we use the default data stream, but others can
be created and used. These are essentially hidden from normal view and
don’t show up in standard tools such as Windows Explorer.
--8<---------------cut here---------------end--------------->8---

Pavel Yosifovich wrote a tool to let us see these streams:

    https://github.com/zodiacon/NtfsStreams

>> 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.

Well said.