4 ms·

The concept presented is something I can agree with in principle, but "transforming a filename into the content of the file" is a really thin justification for

The concept presented is something I can agree with in principle, but "transforming a filename into the content of the file" is a really thin justification for a responsibility. By all means don't build something where you have cascading effect and need to retest an entire pipeline, but this is _not_ it. P.S. And if you really really want to keep it separate, just do "< access.log head -500 etc etc etc" (no I didn't forget a pipe. And yes the "< inputfile" works even if it's in front of what you're calling).

hk__2 3y ago
> And if you really really want to keep it separate, just do "< access.log head -500 etc etc etc" (no I didn't forget a pipe. And yes the "< inputfile" works even if it's in front of what you're calling). Or just use `cat` and let the pipe separate the different steps. "< access.log head" is nice but it breaks this representation where each step is piped into the next one. Sure, once you’re done fiddling you can rewrite the thing to remove the "cat", but when you are constructing the thing I find it clearer to use cat.
- stouset 3y ago
  > Sure, once you’re done fiddling you can rewrite the thing to remove the "cat" Or just… don’t?
  - margalabargala 3y ago
    Sure. Don't. Or do. Whatever you prefer.
- kristjansson 3y ago
  > it breaks this representation where each step is piped into the next one No it doesn't? < access.log head -n 500 | grep mail | perl -e … is completely valid, and reads right-to-left as well as the cat version. IMO using stdin is preferable to either solution in TFA.
  - ufo 3y ago
    This works but it's so ugly :(
    - kristjansson 3y ago
      I think it's beautiful? Reads left-to-right, has nice symmetry if you pipe to an output file like: < infile some_cmd > outfile and real clarifies what's a shell command, what's a redirection, etc.
      - jltsiren 3y ago
        It would make more sense like: infile > some_cmd > outfile Then the arrow would be pointing in the right direction. But then it would be unclear whether "infile" is a file or a command. Which is why people use: cat infile | some_cmd > outfile You can now interpret "cat" as a keyword that specifies that "infile" is a file.
        MatmaRex 3y ago
        It is more pleasant to the eye if you remove the spaces: <infile some_cmd >outfile Just like you wouldn't add spaces in the middle of '2>&1' when redirecting stderr to stdout: <infile some_cmd >outfile 2>&1
        hk__2 3y ago
        > Just like you wouldn't add spaces in the middle of '2>&1' when redirecting stderr to stdout: Mostly because if you do it doesn’t work: '2 >&1' is not the same as '2> &1' (invalid syntax) which is not the same as '2>& 1', which …is the same as '2>&1'.
  - n_plus_1_acc 3y ago
    I agree that it's more elegant, but it requires you to remember the operator precendence of < vs |
TOGoS 3y ago
> transforming a filename into the content of the file" is a really thin justification for a responsibility This is one of those things where I think it is until it isn't. I sometimes second-guess myself when I think I might be over-single-responsibilifying. "Well in practice these two things are so trivial that this feels a little silly." It often turns out to have been a good call in hindsight, especially when working with other people who aren't necessarily thinking about these things at all. If the responsibilities have been sufficiently split up, they're more likely to change only the part that needed to be changed, and less likely to complectify the two things together that really shouldn't've been. Or when I go "oh wow that thing that I thought I overly-abstracted sure composes well with this unexpected new thing!" Hardcore separation of concerns is just another method of defensive programming. > < access.log head -500 etc etc etc It's too bad that the syntax is so different. Why does the first stage not end with "|"? There's space for shell syntax improvements, here. Maybe a 'cat'-like builtin that translates `cat foo | bar` into `bar <foo` so you can have the nice syntax but don't needlessly create processes would leave everyone happy.
ajross 3y ago
> "transforming a filename into the content of the file" is a really thin justification for a responsibility. Uh... I dunno, but my lizard brain thinks that the whole idea of mediating filesystem operations on storage and IPC mechanisms like pipes is a lot more complicated, magic, and deserving of a single command than merely filtering the data on stdin. I agree with the article and the logic, and think this historic meme was basically wrong originally. You string up your chain of pipelines with the first element being "where does it come from?" and not merely whatever the first operation happens to be just because that operation allows for some kind of file input or redirection syntactically.
jiveturkey 3y ago
in the example given in the website, it could all be done in the perl! no need for the pipeline at all.

hk__2 3y ago

> And if you really really want to keep it separate, just do "< access.log head -500 etc etc etc" (no I didn't forget a pipe. And yes the "< inputfile" works even if it's in front of what you're calling). Or just use `cat` and let the pipe separate the different steps. "< access.log head" is nice but it breaks this representation where each step is piped into the next one. Sure, once you’re done fiddling you can rewrite the thing to remove the "cat", but when you are constructing the thing I find it clearer to use cat.

stouset 3y ago
> Sure, once you’re done fiddling you can rewrite the thing to remove the "cat" Or just… don’t?
- margalabargala 3y ago
  Sure. Don't. Or do. Whatever you prefer.
kristjansson 3y ago
> it breaks this representation where each step is piped into the next one No it doesn't? < access.log head -n 500 | grep mail | perl -e … is completely valid, and reads right-to-left as well as the cat version. IMO using stdin is preferable to either solution in TFA.
- ufo 3y ago
  This works but it's so ugly :(
  - kristjansson 3y ago
    I think it's beautiful? Reads left-to-right, has nice symmetry if you pipe to an output file like: < infile some_cmd > outfile and real clarifies what's a shell command, what's a redirection, etc.
    - jltsiren 3y ago
      It would make more sense like: infile > some_cmd > outfile Then the arrow would be pointing in the right direction. But then it would be unclear whether "infile" is a file or a command. Which is why people use: cat infile | some_cmd > outfile You can now interpret "cat" as a keyword that specifies that "infile" is a file.
      - MatmaRex 3y ago
        It is more pleasant to the eye if you remove the spaces: <infile some_cmd >outfile Just like you wouldn't add spaces in the middle of '2>&1' when redirecting stderr to stdout: <infile some_cmd >outfile 2>&1
        hk__2 3y ago
        > Just like you wouldn't add spaces in the middle of '2>&1' when redirecting stderr to stdout: Mostly because if you do it doesn’t work: '2 >&1' is not the same as '2> &1' (invalid syntax) which is not the same as '2>& 1', which …is the same as '2>&1'.
- n_plus_1_acc 3y ago
  I agree that it's more elegant, but it requires you to remember the operator precendence of < vs |

TOGoS 3y ago

> transforming a filename into the content of the file" is a really thin justification for a responsibility This is one of those things where I think it is until it isn't. I sometimes second-guess myself when I think I might be over-single-responsibilifying. "Well in practice these two things are so trivial that this feels a little silly." It often turns out to have been a good call in hindsight, especially when working with other people who aren't necessarily thinking about these things at all. If the responsibilities have been sufficiently split up, they're more likely to change only the part that needed to be changed, and less likely to complectify the two things together that really shouldn't've been. Or when I go "oh wow that thing that I thought I overly-abstracted sure composes well with this unexpected new thing!" Hardcore separation of concerns is just another method of defensive programming. > < access.log head -500 etc etc etc It's too bad that the syntax is so different. Why does the first stage not end with "|"? There's space for shell syntax improvements, here. Maybe a 'cat'-like builtin that translates `cat foo | bar` into `bar <foo` so you can have the nice syntax but don't needlessly create processes would leave everyone happy.

ajross 3y ago

> "transforming a filename into the content of the file" is a really thin justification for a responsibility. Uh... I dunno, but my lizard brain thinks that the whole idea of mediating filesystem operations on storage and IPC mechanisms like pipes is a lot more complicated, magic, and deserving of a single command than merely filtering the data on stdin. I agree with the article and the logic, and think this historic meme was basically wrong originally. You string up your chain of pipelines with the first element being "where does it come from?" and not merely whatever the first operation happens to be just because that operation allows for some kind of file input or redirection syntactically.

jiveturkey 3y ago

in the example given in the website, it could all be done in the perl! no need for the pipeline at all.