6 ms·

Not sure I agree with you there: should it not fork a process to run a heavy task? Should it not fork a process for each end of a pipe, especially considering w

Not sure I agree with you there: should it not fork a process to run a heavy task? Should it not fork a process for each end of a pipe, especially considering we're deep into the multicore era of processors? The fact that the basic shell could use more builtins instead of delegating everything to external processes (like calculating a simple expression) is totally unrelated to the Unix Philosophy being bankrupt. If fork and processes weren't so expensive, I still think multiple processes are the best way to parallelise on multicore CPUs. In fact, there's a resurgence in programming environments based on multiple communicating, yet isolated, processes, see Erlang/Elixir. Though I definitely would like to see someone seriously exploring a different paradigm than UNIX. EDIT: Unix philosophy also is "everything is a file", and what is a file exactly? A bag of bytes. Everything we deal with is a bag of bytes if you think about it, so I find it perfectly fitting to model our world that way. But then again, the current construct to represent this idea such as labels organised in directories, might be a bit long in the tooth and we're due for some paradigm shift on this front as well, but I digress.

DonHopkins 7y ago
So you propose making a "floating point multiply server", even though the CPU can do that in one instruction? Talk about microservices!
- 1_player 7y ago
  Au contraire, I'm saying the shell could turn your multiplication command into a single instruction, no need to call an external process. But at some point you need to delegate to other processes. You can't have /bin/bash embed your Chrome browser in it. But that's not even Unix philosophy. That's how DOS used to work as well.
  - DonHopkins 7y ago
    I'm talking about the shell that actually exists, not some hypothetical shell that doesn't exist and never will. You can't defend the "Unix Philosophy" by proposing a non-standard MONOLITHIC shell be universally adopted that totally goes against what the Unix Philosophy explicitly states: "Make each program do one thing well. To do a new job, build afresh rather than complicate old programs by adding new "features". At least Apple figured out that floating point was useful early enough to replace INTEGER BASIC with APPLESOFT. Forking "bc" from "bash" is the canonical way to multiply two floating point numbers in Unix, according to the "Unix Philosophy". https://stackoverflow.com/questions/12722095/how-do-i-use-floating-point-division-in-bash https://stackoverflow.com/questions/12722095/how-do-i-use-fl... >You can't. bash only does integers; you must delegate to a tool such as bc.
    - Crinus 7y ago
      The shell is meant to pipe programs together, not perform computations itself. Computations are meant to be made by programs, not shell scripts. Use the right tool for the job, do not complain that you screwdriver sucks because you cannot cut wood with it.
      - DonHopkins 7y ago
        You too are blinded by the limitations of your tools. Of course the shell performs all kinds of computations. Just not a useful enough set of them that you don't still need "bc" and "awk" and "sed" and "grep" and many other ridiculous "Unix Philosophy Compliant" tools. I complain my screwdriver sucks when it's made of plastic, and it's only good for driving plastic screws into styrofoam.
        Crinus 7y ago
        The idea is that the tools are meant to be limited to avoid complexity (this is why bash, like most GNU tools, isn't really a good example of unix philosophy - it is too complex) and instead rely on composition.
        DonHopkins 7y ago
        As if the bash syntax for simple string manipulation and piping and quoting and escaping and even determining if a string is empty wasn't unnecessarily complex. As I said, the "Unix Philosophy" of plugging together artificially limited tools by pipes is intellectually bankrupt (and terribly inefficient). That was my whole point.
        mixmastamyk 7y ago
        It is inefficient, but that doesn't matter much for interactive use. After a shell script reaches a dozen lines, it's time to port it to Python. If the job needs absolute performance you rewrite in a performant language instead. I'm not sure why you are upset to be honest? What design would you prefer? This one seems to hit all use cases. In another thread I mention that fish has math and string manipulation builtins.
DonHopkins 7y ago
"Everything is a file". Except ioctl. Except mmap. Except the shell makes it a huge pain in the ass to hook up arbitrary graphs of streams between processes.
- tntn 7y ago
  EDIT: I'm too old for this. Think what you want about mmap and ioctl.
  - DonHopkins 7y ago
    My point is that ioctl and mmap disprove the "Unix Philosophy" idea that files are one-dimensional streams of characters that are all you need to plug programs together.
    - uep 7y ago
      Do they though? Everything as a file is an abstraction, an enormously useful abstraction. The point isn't that it has to behave like a file in every way. At the C level, the fact that open(), read(), write(), or e/poll() behave the similarly is extremely helpful. I can have a whole suite of functions that do not care what type of file descriptor they hold, but just that those functions behave in a predictable way. Maybe only 10% of my code has to care about the differences between them, instead of 70%.
  - pjmlp 7y ago
    Except sockets, Sys V IPC, GPGPUs, better then?
    - deleted 7y ago
      [deleted]
    - p_l 7y ago
      BSD Sockets were never part of "UNIX Philosophy", they are an ugly quick'n'dirty port/rewrite of code from totally alien system (TOPS-20) because DoD had to deal with vendor abandonment

DonHopkins 7y ago

So you propose making a "floating point multiply server", even though the CPU can do that in one instruction? Talk about microservices!

1_player 7y ago
Au contraire, I'm saying the shell could turn your multiplication command into a single instruction, no need to call an external process. But at some point you need to delegate to other processes. You can't have /bin/bash embed your Chrome browser in it. But that's not even Unix philosophy. That's how DOS used to work as well.
- DonHopkins 7y ago
  I'm talking about the shell that actually exists, not some hypothetical shell that doesn't exist and never will. You can't defend the "Unix Philosophy" by proposing a non-standard MONOLITHIC shell be universally adopted that totally goes against what the Unix Philosophy explicitly states: "Make each program do one thing well. To do a new job, build afresh rather than complicate old programs by adding new "features". At least Apple figured out that floating point was useful early enough to replace INTEGER BASIC with APPLESOFT. Forking "bc" from "bash" is the canonical way to multiply two floating point numbers in Unix, according to the "Unix Philosophy". https://stackoverflow.com/questions/12722095/how-do-i-use-floating-point-division-in-bash https://stackoverflow.com/questions/12722095/how-do-i-use-fl... >You can't. bash only does integers; you must delegate to a tool such as bc.
  - Crinus 7y ago
    The shell is meant to pipe programs together, not perform computations itself. Computations are meant to be made by programs, not shell scripts. Use the right tool for the job, do not complain that you screwdriver sucks because you cannot cut wood with it.
    - DonHopkins 7y ago
      You too are blinded by the limitations of your tools. Of course the shell performs all kinds of computations. Just not a useful enough set of them that you don't still need "bc" and "awk" and "sed" and "grep" and many other ridiculous "Unix Philosophy Compliant" tools. I complain my screwdriver sucks when it's made of plastic, and it's only good for driving plastic screws into styrofoam.
      - Crinus 7y ago
        The idea is that the tools are meant to be limited to avoid complexity (this is why bash, like most GNU tools, isn't really a good example of unix philosophy - it is too complex) and instead rely on composition.
        DonHopkins 7y ago
        As if the bash syntax for simple string manipulation and piping and quoting and escaping and even determining if a string is empty wasn't unnecessarily complex. As I said, the "Unix Philosophy" of plugging together artificially limited tools by pipes is intellectually bankrupt (and terribly inefficient). That was my whole point.
        mixmastamyk 7y ago
        It is inefficient, but that doesn't matter much for interactive use. After a shell script reaches a dozen lines, it's time to port it to Python. If the job needs absolute performance you rewrite in a performant language instead. I'm not sure why you are upset to be honest? What design would you prefer? This one seems to hit all use cases. In another thread I mention that fish has math and string manipulation builtins.

DonHopkins 7y ago

"Everything is a file". Except ioctl. Except mmap. Except the shell makes it a huge pain in the ass to hook up arbitrary graphs of streams between processes.

tntn 7y ago
EDIT: I'm too old for this. Think what you want about mmap and ioctl.
- DonHopkins 7y ago
  My point is that ioctl and mmap disprove the "Unix Philosophy" idea that files are one-dimensional streams of characters that are all you need to plug programs together.
  - uep 7y ago
    Do they though? Everything as a file is an abstraction, an enormously useful abstraction. The point isn't that it has to behave like a file in every way. At the C level, the fact that open(), read(), write(), or e/poll() behave the similarly is extremely helpful. I can have a whole suite of functions that do not care what type of file descriptor they hold, but just that those functions behave in a predictable way. Maybe only 10% of my code has to care about the differences between them, instead of 70%.
- pjmlp 7y ago
  Except sockets, Sys V IPC, GPGPUs, better then?
  - deleted 7y ago
    [deleted]
  - p_l 7y ago
    BSD Sockets were never part of "UNIX Philosophy", they are an ugly quick'n'dirty port/rewrite of code from totally alien system (TOPS-20) because DoD had to deal with vendor abandonment