Unix and Flow-Based Programming
groups.google.com
Unix and Flow-Based Programming
1–10 of 27 posts
Re: Unix and Flow-Based Programming
#2> Then Torvalds open-sourced linux and that is what started to gain popularity.
cough BSDi cough
Re: Unix and Flow-Based Programming
#3> Wildly simple - it takes at most one argument.
That is asinine. Why would a program be called ‘cat’ if it can’t concatenate multiple files?
Also, his “grash” program is seriously deficient in the handling of signals – it completely ignores the issue. There are many subtle issues with signals which have to be handled correctly when writing a shell: http://www.cons.org/cracauer/sigint.html
Re: Unix and Flow-Based Programming
#4> I was going to mention Unix “cat” but forgot. > Wildly simple - it takes at most one argument. That is asinine. Why would a program be called ‘cat’ if it can’t con cat enate multiple files? Also, his “grash” program is seriously deficient in the handling of signals – it completely ignores the issue. There are many subtle issues with signals which have to be handled correctly when writing a shell: http://www.cons.or…
Re: Unix and Flow-Based Programming
#5> I was going to mention Unix “cat” but forgot. > Wildly simple - it takes at most one argument. That is asinine. Why would a program be called ‘cat’ if it can’t con cat enate multiple files? Also, his “grash” program is seriously deficient in the handling of signals – it completely ignores the issue. There are many subtle issues with signals which have to be handled correctly when writing a shell: http://www.cons.or…
Re: Unix and Flow-Based Programming
#6> I was going to mention Unix “cat” but forgot. > Wildly simple - it takes at most one argument. That is asinine. Why would a program be called ‘cat’ if it can’t con cat enate multiple files? Also, his “grash” program is seriously deficient in the handling of signals – it completely ignores the issue. There are many subtle issues with signals which have to be handled correctly when writing a shell: http://www.cons.or…
Re: Unix and Flow-Based Programming
#7> I was going to mention Unix “cat” but forgot. > Wildly simple - it takes at most one argument. That is asinine. Why would a program be called ‘cat’ if it can’t con cat enate multiple files? Also, his “grash” program is seriously deficient in the handling of signals – it completely ignores the issue. There are many subtle issues with signals which have to be handled correctly when writing a shell: http://www.cons.or…
Because he only thinks it's the "echo file to terminal" command.
The main use of cat was mentioned in the Programming in the UNIX environment article.
> The fact that cat will also print on the terminal is a special case. Perhaps surprisingly, in practice it turns out that the special case is the main use of the program. [...] But what about -v? That prints non-printing characters in a visible representation. Making strange characters visible is a genuinely new function, for which no existing program is suitable. [...] The answer is ‘‘No.’’ Such a modification confuses what cat ’s job is concatenating files with what it happens to do in a common special case - showing a file on the terminal.
Re: Unix and Flow-Based Programming
#8> I was going to mention Unix “cat” but forgot. > Wildly simple - it takes at most one argument. That is asinine. Why would a program be called ‘cat’ if it can’t con cat enate multiple files? Also, his “grash” program is seriously deficient in the handling of signals – it completely ignores the issue. There are many subtle issues with signals which have to be handled correctly when writing a shell: http://www.cons.or…
> That is asinine. Why would a program be called ‘cat’ if it can’t concatenate multiple files? Because he only thinks it's the "echo file to terminal" command. The main use of cat was mentioned in the Programming in the UNIX environment article. > The fact that cat will also print on the terminal is a special case. Perhaps surprisingly, in practice it turns out that the special case is the main use of the program. [.…
Re: Unix and Flow-Based Programming
#9Earlier quoted context omitted.
> That is asinine. Why would a program be called ‘cat’ if it can’t concatenate multiple files? Because he only thinks it's the "echo file to terminal" command. The main use of cat was mentioned in the Programming in the UNIX environment article. > The fact that cat will also print on the terminal is a special case. Perhaps surprisingly, in practice it turns out that the special case is the main use of the program. [.…
Like a lot of people, he overuses cat when it's not needed. `cat FOO | more` is approximately equivalent to `more < FOO`, except the first one spawns an extra process for no reason.
I wonder how many processes I could spin up in the time it would take for me to figure out "hmm, no, invoking that command would use one more process than necessary..."
I don't give a hoot about that stuff when I'm doing stuff interactively. e.g. when using `more`.
Re: Unix and Flow-Based Programming
#10> I was going to mention Unix “cat” but forgot. > Wildly simple - it takes at most one argument. That is asinine. Why would a program be called ‘cat’ if it can’t con cat enate multiple files? Also, his “grash” program is seriously deficient in the handling of signals – it completely ignores the issue. There are many subtle issues with signals which have to be handled correctly when writing a shell: http://www.cons.or…
"cat" sounds like the abbreviation of "catenate" not "concatenate". Perhaps its possible that later versions of cat allowed more than one argument?