3 ms·

If you do this, this will break every program which takes text based filenames on command line.. which is most of ghem. It is an interesting idea, but I don't t

by theamk 5y ago

If you do this, this will break every program which takes text based filenames on command line.. which is most of ghem. It is an interesting idea, but I don't think it would be Unix anymore.

jbverschoor 5y ago
'Unix' is too low level anyway.. Unix is about reading/writing byte streams.. I don't think the "interactive shell" was meant for scripting anyway. It's like writing your scripts in selenium similar tools. Someone only needs to change the structure or order of the webpage, and you have a problem, depending on how you do your scraping / interacting with the output. No experience with powershell, but sounds great.
- conradludgate 5y ago
  I dont think unix was every truly about byte streams. Make each program do one thing well. To do a new job, build afresh rather than complicate old programs by adding new "features". Is the core point. Later editions went on to specify text as the preferred language for these programs to communicate in but I don't think that's key to upholding the unix philosophy. It was just the easiest to work with at the time We just need to agree upon a common framework for these programs to communicate with. There will definitely be a lot of churn though
  - jbverschoor 5y ago
    > Make each program do one thing well. To do a new job, build afresh rather than complicate old programs by adding new "features". That's a quote from '78, by the Doug McIlroy, the inventor of Unix pipes. Pipes are exactly that... reading and writing bytestreams. Also him: - (ii) Expect the output of every program to become the input to another, as yet unknown, program. Don't clutter output with extraneous information. Avoid stringently columnar or binary input formats. Don't insist on interactive input. Later: Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface. (https://homepage.cs.uri.edu/~thenry/resources/unix_art/ch01s06.html https://homepage.cs.uri.edu/~thenry/resources/unix_art/ch01s...) I mean come one. "ls" grew from a simple tool with 11 parameters to 58 parameters. source: https://news.ycombinator.com/item?id=29568042 https://news.ycombinator.com/item?id=29568042 / https://danluu.com/cli-complexity/ https://danluu.com/cli-complexity/ This only happens because people are scripting in their ui. They shouldn't. "Unix admins" laugh at people who do the exact same things within office or other GUI solutions. Using "text streams".. yes, for performance, a stream is better. Same with SAX vs DOM. nobody likes SAX

by theamk 5y ago

If you do this, this will break every program which takes text based filenames on command line.. which is most of ghem. It is an interesting idea, but I don't think it would be Unix anymore.

jbverschoor 5y ago

'Unix' is too low level anyway.. Unix is about reading/writing byte streams.. I don't think the "interactive shell" was meant for scripting anyway. It's like writing your scripts in selenium similar tools. Someone only needs to change the structure or order of the webpage, and you have a problem, depending on how you do your scraping / interacting with the output. No experience with powershell, but sounds great.

conradludgate 5y ago
I dont think unix was every truly about byte streams. Make each program do one thing well. To do a new job, build afresh rather than complicate old programs by adding new "features". Is the core point. Later editions went on to specify text as the preferred language for these programs to communicate in but I don't think that's key to upholding the unix philosophy. It was just the easiest to work with at the time We just need to agree upon a common framework for these programs to communicate with. There will definitely be a lot of churn though
- jbverschoor 5y ago
  > Make each program do one thing well. To do a new job, build afresh rather than complicate old programs by adding new "features". That's a quote from '78, by the Doug McIlroy, the inventor of Unix pipes. Pipes are exactly that... reading and writing bytestreams. Also him: - (ii) Expect the output of every program to become the input to another, as yet unknown, program. Don't clutter output with extraneous information. Avoid stringently columnar or binary input formats. Don't insist on interactive input. Later: Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface. (https://homepage.cs.uri.edu/~thenry/resources/unix_art/ch01s06.html https://homepage.cs.uri.edu/~thenry/resources/unix_art/ch01s...) I mean come one. "ls" grew from a simple tool with 11 parameters to 58 parameters. source: https://news.ycombinator.com/item?id=29568042 https://news.ycombinator.com/item?id=29568042 / https://danluu.com/cli-complexity/ https://danluu.com/cli-complexity/ This only happens because people are scripting in their ui. They shouldn't. "Unix admins" laugh at people who do the exact same things within office or other GUI solutions. Using "text streams".. yes, for performance, a stream is better. Same with SAX vs DOM. nobody likes SAX