out of space on /root

[Xen]

Paul Smith schreef op 06-03-2017 15:37:
> On Mon, 2017-03-06 at 14:10 +0100, Xen wrote:
>> > so it is better to to just "tail".
>> 
>> Yes, that's what I said ;-).
> 
> I think for helping new people it's better to provide the best answer
> only and leave it at that, rather than provide a not-so-good answer
> first and then say "maybe it would be better to do XYZ"... :)

Maybe, but anyone really interested in the answer instead of only 
responding to 'improve' it would probably read the entire message.

And that becomes more educational as well, although I admit my wording 
was a bit ambiguous.

I prefer people to do a little thinking you know, but yeah.


> The other example in this email is also a UUOC:
> 
>> cat "file" | split -b 500M
> 
> can be more efficiently written:
> 
>   split -b 500M < "file"

I disagree. The second expression is harder to write mentally and more 
prone to error. There is barely a functional difference apart from the 
extra cat process, but this doesn't really take any resources. It's 
either Bash doing it, or Cat, there is no other difference.

It's much more natural to use the pipe verbatim because you can easily 
expand it and do a lot more with it. In fact

< "file" split -b 500M would also be perfectly the same, but you see how 
unreadable it becomes.

Meaning, when you start writing your expression, the pipe syntax takes 
less mental resources at the start, I mean you have to think less about 
how long your expression is going to be or whatever.

It is also more natural to feed something from left to right, but your 
mileage may vary.

I just disagree with your sentiment, that's all. The saving of the extra 
cat process is just not worth it. I hope we can each have our own style 
here.

I mean, I hope you wouldn't seriously consider writing something like

grep text < file | sed | tac > file.

That makes for very unreadable and unmanageable code.

Not every program requests the "file" parameter in the same way, so in 
general cat is ubiquitously useful. It always works. Except when you 
have very large seeks, very large streams resulting from the thing. You 
can't seek in a pipe you know, but you knew that.

However the "cat pipe" versus "bash redirect" syntax makes generally no 
difference. It is insignificant. There is still going to be a process 
receiving something on stdin, it's just that Bash will be on the other 
end instead of Cat.

It is also more complicated for a beginner to use the syntax you advise.

You now ask this beginner to worry about insignificant performance 
gains, when no one, and certainly no beginner, will ever notice that.

So I don't mind if you use that syntax, but please don't berate others 
for using the other style when it is, in fact, better.


> In general, cat can almost always be avoided giving a more efficient
> (sometimes GREATLY more efficient depending on the situation, other
> times just a little bit more efficient) result.

I would actually be curious as to what those greatly more efficient 
situations would be, if you don't mind.