🌐 Mailman 3 August 2021 - Python-list - python.org

Re: some problems for an introductory python test
by Hope Rouselle Aug. 17, 2021

Aug. 17, 2021

Dennis Lee Bieber <wlfraed(a)ix.netcom.com> writes: > On Thu, 12 Aug 2021 06:15:28 +1000, Chris Angelico <rosuav(a)gmail.com> > declaimed the following: > >>The default command interpreter and shell on OS/2 was fairly primitive >>by today's standards, and was highly compatible with the MS-DOS one, >>but it also had the ability to run REXX scripts. REXX was *way* ahead >>of its time. It's a shell language but remarkably well suited to >>building GUIs and other tools (seriously, can you imagine designing a >>GUI entirely in a bash script??). It had features that we'd consider >>fairly normal or even primitive by Python's standards, but back then, >>Python was extremely new and didn't really have very much mindshare. >>REXX offered arbitrary-precision arithmetic, good databasing support, >>a solid C API that made it easy to extend, integrations with a variety >>of other systems... this was good stuff for its day. (REXX is still >>around, but these days, I'd rather use Python.) >> > I was spoiled by the Amiga variant of REXX. Most current > implementations (well, Regina is the only one I've looked at) can just pass > command to the default shell. The Amiga version took advantage of Intuition > Message Ports (OS supported IPC). That allowed it to "address > <application>" any application that defined an ARexx port, allowing ARexx > to be used as a scripting language for that application (and with multiple > applications, one could easily fetch data from app1 and feed it to app2). > ARexx did not, to my memory, implement arbitrary precision math. > > Any statement in a REXX script that was not parsable as REXX would be > passed on the currently "addressed" command host. > > Granted, the fact that the Amiga used a shared common address space for > all running applications made IPC quite easy -- one looked up the > application message port, then added a small packet to the linked list > associated with the port. That small packet basically held the address of > the message port for returning data, and the address of the data being > passed. The closet thing I've seen to that capability on systems with > process-isolated virtual memory is (Open)VMS "mailbox" structures. The > difference being that the entire data had to be written (QIO) to the > mailbox, and the receiver had to read (another QIO call) the message -- > this allowed the address space to change. > > I've not seen anything equivalent in my light perusal of the Win32 API > (the various guide books aren't layed out in any way to be a reference), > and Linux seems to use UNIX sockets for IPC... No way to search for a > connection point by name... I don't know anything about Amiga, REXX et cetera, so I might be totall off here. But since you spoke of your perusal of the Win32 API, let me add a tiny bit. I gave myself a quick tour through the Win32 API using Pavel Yosifovich's book ``Windows 10 System Programming''. It's a two volume work. The thing that impressed me the most was the many ways to do the IPC. The purpose the work is clearly to show what is available and it it probably does the job well. (I ignored Windows for most of my life and now I decided to take a look at it. I don't feel it has much of the elegance of UNIX. It's what it is.)

2 1

please help
by vitalis Aug. 17, 2021

Aug. 17, 2021

I keep getting this error while trying to install pyqt5 designer Fatal error in launcher: Unable to create process using '"c:\program files\python39\python.exe" "C:\Program Files\Python39\Scripts\pip.exe" install PyQt5Designer': The system cannot find the file specified. please what do I do about this Sent from [1]Mail for Windows References Visible links 1. https://go.microsoft.com/fwlink/?LinkId=550986

3 2

Re: on slices, negative indices, which are the equivalent procedures?
by Jack Brandom Aug. 17, 2021

Aug. 17, 2021

Dennis Lee Bieber <wlfraed(a)ix.netcom.com> writes: > On Wed, 11 Aug 2021 11:59:11 -0300, Jack Brandom <jbrandom(a)example.com> > declaimed the following: > >> >>Where are these production rules coming from? They're not at >> >> https://docs.python.org/3/reference/grammar.html >> >>The word ``stride'' doesn't appear in this grammar. > > Possibly from older versions of the grammar, before simplification to > just <expression>. Originally, the "stride" term was added in response to > requests from the numerical library developers (NumPy seems to be the > survivor of that cluster). At the time, it wasn't envisioned to be usable > with regular Python objects. > > https://en.wikipedia.org/wiki/Array_slicing#1991:_Python > """ > The stride syntax (nums[1:5:2]) was introduced in the second half of the > 1990s, as a result of requests put forward by scientific users in the > Python "matrix-SIG" (special interest group). > """ Always great to know the history with good references. Thanks very much. > As for the grammar... Would you prefer that from 2.7? > > trailer: '(' [arglist] ')' | '[' subscriptlist ']' | '.' NAME > subscriptlist: subscript (',' subscript)* [','] > subscript: '.' '.' '.' | test | [test] ':' [test] [sliceop] > sliceop: ':' [test] > > test: or_test ['if' or_test 'else' test] | lambdef > or_test: and_test ('or' and_test)* > and_test: not_test ('and' not_test)* > not_test: 'not' not_test | comparison This is looking less readable, so, no, I prefer that previous, which was much clearer about slices. I can't even quite make the slices out in these rules. (But thanks for the opportunity to try.)

2 1

some problems for an introductory python test
by Hope Rouselle Aug. 16, 2021

Aug. 16, 2021

I'm looking for questions to put on a test for students who never had any experience with programming, but have learned to use Python's procedures, default arguments, if-else, strings, tuples, lists and dictionaries. (There's no OOP at all in this course. Students don't even write ls.append(...). They write list.append(ls, ...)). I'd like to put questions that they would have to write procedures that would would be real-world type of stuff, without error checking, exceptions and such. So if you think of something more or less cool that uses loops, we can sometimes simplify it by assuming the input has a certain fixed size. I came up with the following question. Using strings of length 5 (always), write a procedure histogram(s) that consumes a string and produces a dictionary whose keys are each substrings (of the string) of length 1 and their corresponding values are the number of times each such substrings appear. For example, histogram("aaaaa") = {"a": 5}. Students can "loop through" the string by writing out s[0], s[1], s[2], s[3], s[4]. I'd like even better questions. I'd like questions that would tell them to write procedures that would also have inverses, so that one could check the other of the other. (A second question would ask for the inverse, but hopefully real world stuff. One such question could be parsing a line separate by fields such as "root:0:0:mypass:Super User" and another that gives them ["root", 0, 0, ...] and asks them to write "root:0:0:mypass:..." You get the idea.) Students know how to use str(). But they don't know how to use type(), so they can't really check for the type of the input. I probably couldn't ask them to write a prototype of a tiny subset of pickle, say. I think you get the idea. I hope you can provide me with creativity. I have been looking at books, but every one I look at they introduce loops very quickly and off they go. Thank you!

4 6

Re: some problems for an introductory python test
by Hope Rouselle Aug. 16, 2021

Aug. 16, 2021

Chris Angelico <rosuav(a)gmail.com> writes: > On Fri, Aug 13, 2021 at 2:15 AM Hope Rouselle <hrouselle(a)jevedi.com> wrote: >> >> Chris Angelico <rosuav(a)gmail.com> writes: >> >> > History lesson! >> > >> > Once upon a time, IBM and Microsoft looked at what Intel was >> > producing, and went, hey, we need to design an operating system that >> > can take advantage of the fancy features of this 80286 thing. So they >> > collaborate on this plan to make a 16-bit protected mode OS. >> > Unfortunately, things didn't work out too well, partly because this >> > was when Microsoft was at its most monopolistic, and they ended up >> > parting company. IBM continued to make OS/2, but Microsoft took their >> > part of the code and made Windows NT out of it. >> >> How is it possible that Microsoft would take part of the code of OS/2? >> Did IBM just hand it to them? > > I presume both companies had all of the code. It was a matter of > licensing, though. There were a few components that were saddled with > awkward restrictions due to the dual ownership (for instance, HPFS386 > was Microsoft-controlled, but vanilla HPFS was fine - kinda like the > difference between LZW and LZ77). > >> > (Aside: Windows NT's 16-bit applications and OS/2's 16-bit >> > applications were actually identical and compatible. Unfortunately, >> > Win32 introduced a very new API, so as soon as everyone moved to >> > 32-bit everything, the schism became problematic. But it was actually >> > possible to package up a single .EXE file with a 16-bit MS-DOS loader, >> > a Win32 loader, and an OS/2 32-bit loader, all happily coexisting. >> >> Beautiful. :-) So if all libraries were around in each system, they had >> perfect compatibility? > > The 16-bit loaders were fine, but the 32-bit loaders were different, > so this trick basically meant having three different copies of the > code wrapped up in a single executable. > >> > 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? 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.) > > Something like that, but with a lot more metadata. Modern OSes don't > seem to work that way any more. > >> 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? > > Kinda, but instead of having the choice of interpreter be inside the > file contents itself, the choice was in the file's metadata. Still > part of the file, but if you open and read the file, it isn't any > different. Speaking of which, NTFS supports something called file streams. That's essentially a way to have files inside files. Streams are not shown by tools such as file explorer. Applications could definitely use that as metadata. (End of tangent.) I think UNIX people would say and I'd agree --- we have that already. But instead of hiding the stream, which is obscurantism, we let the user see. (Just create two files in a directory, one with the extension .metadata. And, oh, if you don't like that extension, you can change it to whatever you like. Lol.) I like that. >> > The default command interpreter and shell on OS/2 was fairly primitive >> > by today's standards, and was highly compatible with the MS-DOS one, >> > but it also had the ability to run REXX scripts. REXX was *way* ahead >> > of its time. It's a shell language but remarkably well suited to >> > building GUIs and other tools (seriously, can you imagine designing a >> > GUI entirely in a bash script??). >> >> I cannot imagine. I always wondered what REXX was about --- I saw >> programs sometimes written in some website whose name is something like >> Rosetta Code. REXX looked so weird. (``Who would program in that?'') >> But I see now there is a context to it. > > Yeah. It was a strange choice by today's standards, but back then, > most of my GUI programs were written in REXX. > > https://en.wikipedia.org/wiki/VX-REXX > http://www.edm2.com/0206/vrexx.html > > (There were other tools too - VisPro REXX, VREXX, DrDialog, and > various others - but VX-REXX was where most of my dev work happened.) I like that kind of simpler GUI interface. Cleaner. Fast! You know, the so-called ``modern world'' is totally overrated. >> > Probably the most >> > notable feature, by today's standards, was that it had a single input >> > queue. ... This means that, if the response to a >> > keystroke is to change focus, then *even in a slow and lagged out >> > system*, subsequent keys WOULD be sent to the new target window. That >> > was AWESOME, and I really miss it. Except that I also don't. Because >> > if a single application is having issues, now your entire keyboard and >> > mouse is locked up... which kinda slightly sucks. Good luck resolving >> > that problem. (We had some neat tools like WatchCat that could get >> > around the single input queue via interrupt signals, and regain >> > control. But it was still problematic.) >> >> Wow, I kinda feel the same as you here. I think this justifies perhaps >> using a hardware solution. (Crazy idea?! Lol.) > > uhhh........ Yes. Very crazy idea. Can't imagine why anyone would ever > think about doing that. Lol. Really? I mean a certain panic button. You know the GNU Emacs. It has this queue with the implications you mentioned --- as much as it can. (It must of course get the messages from the system, otherwise it can't do anything about it.) And it has the panic button C-g. The keyboard has one the highest precedences in hardware interrupts, doesn't it not? A certain very important system could have a panic button that invokes a certain debugger, say, for a crisis-moment. But then this could be a lousy engineering strategy. I am not an expert at all in any of this. But I'm surprised with your quick dismissal. :-) > Certainly nobody in his right mind would have WatchCat listening on > the serial port's Ring Indicator interrupt, and then grab a paperclip > to bridge the DTR and RI pins on an otherwise-unoccupied serial port > on the back of the PC. (The DTR pin was kept high by the PC, and could > therefore be used as an open power pin to bring the RI high.) Why not? Misuse of hardware? Too precious of a resource? > If you're curious, it's pins 4 and 9 - diagonally up and in from the > short > corner. http://www.usconverters.com/index.php?main_page=page&id=61&chapter=0 You know your pins! That's impressive. I thought the OS itself could use something like that. The fact that they never do... Says something, doesn't it? But it's not too obvious to me. > And of COURSE nobody would ever take an old serial mouse, take the > ball out of it, and turn it into a foot-controlled signal... although > that wasn't for WatchCat, that was for clipboard management between my > app and a Windows accounting package that we used. But that's a > separate story. Lol. I feel you're saying you would. :-) >> Maybe machine and OS >> could have a desktop-version that would have a hardware that could >> effectively be like a second keyboard --- a button. So our keywords >> would have a button that we press it, we could interrupt the OS to >> handle such lock-up more gracefully. I suppose this is expensive, >> complex and so on. But at the same time, it could be worth it. > > SysRq should theoretically be that. (That's Alt+PrtSc on a lot of > keyboards.) I'm not sure how it could best be handled though. It might > be that today's GUI systems (X11, Wayland, Cocoa, Win32, etc) just > wouldn't work with a single input queue. Would be curious to see if > any modern OS/GUI pair has a synchronous input queue like that. I just pressed M-PrtSc on my keyboard. Windows 10. Nothing happened. (I'm not aware of any synchronous input queue liked you said either.) >> > So, yeah. It was spectacular in its day.... but it kinda got left >> > behind as the world moved on. These days, instead of running REXX code >> > on OS/2 in a system that uses eight-bit text for most things, I use >> > Python on Linux and full Unicode. But OS/2 was an important part of >> > history, both my own personal journey, and the history of the world of >> > PCs. >> >> Very nice. Thanks a lot for sharing. I care a lot about such >> histories. In fact, if you could point out from the top of your head >> the best reference on the facts you mentioned here, I would love to >> write it down for future reference. (You probably read books that >> perhaps explained how the queue of windows messages worked et cetera.) >> >> Thank you! > > Thank you for asking questions about it! Aside from making me feel old > (which, let's face it, is kinda inevitable), it's great to dig through > some of the history and a few of the very different ways things have > been done. I am in my early fourties. I can clearly see how kids look at me as old. It's really not so bad. Some are born earlier. :-) And it turns out life a few decades ago was really not so bad. Things seem to be getting rougher now. I feel sorry for kids. What we should do, though, is preserve our health. Older people in good health seem sometimes even happier than the youngsters. > References, unfortunately, are a bit hard to share, since they're > mostly dead-tree books, plus a small number of IPF documents (a format > kinda like man pages, but they get compiled) which have probably been > lost by now. Oh, plus a lot of "My dad told me", which is a bit hard > to point anyone else to :) > > But if you want to delve into things today, I would recommend using > Wikipedia or whatever the almighty Google shows up, neither of which > was available back then, but both of which have vast information > available to you. Some useful topics: > > * Single (or Synchronous) Input Queue > * CORBA (the system for cross-language subclassing of PM classes) > * The OS/2 Presentation Manager > * 80386 Protected Mode > * DBCS (early multilanguage support - appallingly inferior to Unicode, > but better than nothing) > * REXX, VX-REXX, VPREXX, VREXX > * DB2 (IBM's flagship database both then and now; spectacular even > back then, although slow at times) Thank you so much. That's good enough. > Python *was* available on OS/2 back then, but not heavily supported. > It might be interesting to compare the early versions of Python to the > other tools available, but probably more useful to compare the 1990s > tools to modern Python on modern OSes and see how far the world has > come. I heard of Python for the first time in the 90s. I worked at an ISP. Only one guy was really programming there, Allaire ColdFusion. But, odd enough, we used to say we would ``write a script in Python'' when we meant to say we were going out for a smoke. I think that was precisely because nobody knew that ``Python'' really was. I never expected it to be a great language. I imagined it was something like Tcl. (Lol, no offense at all towards Tcl.)

2 1

fixed the from fiield
by testing Aug. 15, 2021

Aug. 15, 2021

heh -- Python Test Script .

1 0

post.py
by Testing＠python.nntp.script Aug. 15, 2021

Aug. 15, 2021

Just got done writing this nice little posting script. Its my first python script ecer so be nice lol. #!/usr/bin/python3 import nntplib import sys NAME = 'testbunny' EMAIL = 'testy(a)test.com' SIG = 'Testbunny' ORG = 'Python Pirates' SERVER = 'nntp.aioe.org' GROUPS = 'alt.test' SUBJECT = input("What is the subject? ") print("Enter/Paste your content. Ctrl-D or Ctrl-Z ( windows ) to save it.") contents = [] while True: try: BODY = input() contents.append(BODY) except EOFError: break text = '\n'.join(contents) open('article.txt', 'w').close() with open('article.txt', 'a') as f: f.write('From: ' + NAME + " <" + EMAIL + ">") f.write("\n") f.write('Subject: ' + SUBJECT) f.write("\n") f.write('Newsgroups: ' + GROUPS) f.write("\n") f.write('Organization: ' + ORG) f.write("\n") f.write('User-Agent: Python3') f.write("\n") f.write("\n") f.writelines(text) f.write("\n") f.write("\n") f.write('--') f.write("\n") f.write(SIG) f.write("\n") f.write('.') print("Sending article....") s = nntplib.NNTP(SERVER) f = open('article.txt', 'rb') s.post(f) print("done") s.quit() -- Python Test Script .

1 0

Re: some problems for an introductory python test
by Hope Rouselle Aug. 15, 2021

Aug. 15, 2021

Dennis Lee Bieber <wlfraed(a)ix.netcom.com> writes: > On Wed, 11 Aug 2021 09:27:38 -0300, Hope Rouselle <hrouselle(a)jevedi.com> > declaimed the following: >> >>I wouldn't. This is all Python-stuff. The course chooses a language >>like Python, but it is not trying to teach Python --- it is trying to >>teach computer programming, that is, strategies in high-precision. > > Then I would posit you are teaching the wrong level... What you > describe is what would be found a "data structures" and/or "algorithms" > course -- which is a second year, if not third year course in my (ancient) > history. [...] Slicing with a stride isn't really useful to most > algorithm development -- it's more of trick in normal Python. I didn't express myself very well. And it's hard to make sense of the course. I say it's interested in teaching computer programming because it is not allowing the students to dive into the Python language. It's very restrictive. Students will finish the course after learning to use the loop contructs while and for. The course calls them ``structures for repetition''. I think it's safe to say that the course is designed by people concerned with education, but not well-versed in programming languages, so not even the terminology seems quite correct. So if they're not letting students embrace the whole of the language, they must be concerned with other things? They sloppily emphasize documentation and put in some concerns for procedure signatures. I have some trouble defending it. I see the good intentions, though, and the job is not easy. But this course is definitely not teaching any data structures or any algorithms. Zero. Students are using tuples, lists and dictionaries, strings and numbers, but they're not studying any strategies whatsoever. The exercises make students use a few basic facts of mathematics, but there is pretty much no investigation into the strategies behind some of these facts. It's not very intelligible. I *kinda* like that it's restrictive because it allows us to show students at least a few idioms: otherwise there's so much syntax to digest that there is no time to show a few useful applications of them. But then I read your next paragraph and it brings me to a very important point, which I think it's at the back of your mind too. Let's see. > So... The first thing I would drop is the RESTRICTION to only use what > you've covered in prior sessions... Let the students read the language > reference manual, peruse the library reference manual, and allow them to > use whatever "advanced" techniques they are able to understand on their > own. Precisely. We kill the spirit of investigation by saying --- don't do anything I don't allow you to. This is pretty dangerous. I have a much better idea, I think. You have to give people a tool and say --- use however you want. If we don't want them to use things not introduced in previous lessons, we should give them a precisely-limited tool. But that's not done. The much better idea is to use such a limited language. There are such languages, made precisely for teaching. It comes with very little syntax and lesson after lesson it gets immensely powerful with very little syntax. > Granted you may have to restrict some features if [...] To let students use the entire language feels a bit weird in the sense that the group goes in so many different directions. It definitely put teachers in a position they have to be --- I don't know the answer. It is not my case. But I do think that holding a class with wildly different backgrounds, each going about in their own weird ways is kinda odd. It doesn't seem to bring people together --- on average. The better-idea brings people together by leveling everyone out. Unpopular languages give us this feature. Students hardly ever master them. It's a game nobody played. The rules are very simple. The implications are far-fetching. Sometimes even the programmer-expert in class realizes he is less skilled than the total-novice that never handled a compiler: his tricks don't work in the new game. (It's not that we don't allow him to use them. They're not there. They don't compile.) (We take Ghess players, Backgammon and Checkers players [the students], we teach them a new game, say, Go, and suddenly everyone is learning together. Assume Go is unpopular. It's very simple. Everyone learns the rules quickly and we spend the semester looking into strategies. Much better idea.) > For my Algorithm/Data Structure course (circa 1978), the instructor > allowed us to use any language /he/ could understand (so no SNOBOL). At the > time I'd gone through intro/advanced FORTRAN-4, intro/advanced COBOL, Sigma > Assembly, UCSD Pascal (not on the campus main computer, just a pair of > LSI-11s), and BASIC. The assignment was a "Hashed Head, Multiply-Linked > List". I chose to do that assignment using BASIC! In nearly 45 years, I've > only seen ONE real-world implementation of the HHMLL -- The file system > used by the Commodore Amiga. (Hash the first component of the path/name, > that maps to one of 64 entries in the root directory block; each entry > points the start of a linked list, follow the list until you reach the > block with the component name; if it is a directory block, hash the next > component and repeat; if it is a file block, the "entries" point to data > blocks instead of lists) Repeating my criticism with one more illustration. When ``there's always more than one way to do it'', students can't even count on their classmates to help each other --- because each one is doing a different thing. This is good in science, but what I like the most in schooling is working together and too much freedom like seems not very helpful in this direction. But both worlds is possible. Use a limited tool (which is not computationally limited, quite the contrary) and tell them --- you can do anything you want with this. The effect is that everyone, although everyone is more or less original, the different solutions are never too far apart, so all the exchange is quite possible.

1 1

Re: Regarding inability of Python Module Winsound to produce beep in decimal frequency
by jak Aug. 15, 2021

Aug. 15, 2021

Il 13/08/2021 18:17, Chris Angelico ha scritto: > On Sat, Aug 14, 2021 at 2:11 AM Terry Reedy <tjreedy(a)udel.edu> wrote: >> >> On 8/13/2021 6:53 AM, Umang Goswami wrote: >>> Hi There, Hope you find this mail in good health. >>> >>> I am Umang Goswami, a Python developer and student working on a huge >>> project for automation of music instruments. I am producing the musical >>> notes using the Beep function of Winsound Module( >>> https://docs.python.org/3/library/winsound.html) by passing frequency as a >>> argument to the function. >>> >>> Now whenever i provide frequency of any note in decimal(for example >>> 277.1826 for C4 note) it shows following error: >>> Traceback (most recent call last): >>> File "C:\Users\Umang Goswami\Desktop\Umang Goswami\test.py", line 2, in >>> <module> >>> winsound.Beep(111.11,111111) >>> TypeError: integer argument expected, got float >>> >>> Now I have to round up the frequencies. This is hurting the quality, >>> accuracy ,authenticity and future of the project. Almost all the notes have >>> the frequencies in decimal parts. Rounding up means changing semitones and >>> quatertones thus whole note itself. This problem is technically making my >>> program useless. >>> > > Is it really? In my experience, no human ear can distinguish 277Hz > from 277.1826Hz when it's played on a one-bit PC speaker, which the > Beep function will be using. > > ChrisA > Hi, you could use a trick to get a better approximation: 277 * 4 = 1108 278 * 1 = 278 1108 + 278 = 1386 1386/5 = 277.2 now, respecting the duration of the tone, in accordance with its simple rate, the buffer to be played will become: 277, 277, 277, 277, 278, 277, 277, 277, 277, 278, 277, 277, ... and so on.

1 0

Re: some problems for an introductory python test
by Hope Rouselle Aug. 15, 2021

Aug. 15, 2021

Grant Edwards <grant.b.edwards(a)gmail.com> writes: > On 2021-08-12, Hope Rouselle <hrouselle(a)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.

1 0