On 1/23/21 5:19 PM, Anders Damsgaard wrote: > (lots of Cc's removed) > > * Alejandro Colomar <alx.manpa...@gmail.com> [2021-01-22 00:12:58 +0100]: > >> This is useful for using tee to just write to a file, >> at the end of a pipeline, >> without having to redirect to /dev/null. >> >> Example: >> echo 'foo' | sudo tee -q /etc/foo; >> is equivalent to the old (and ugly) >> echo 'foo' | sudo tee /etc/foo >/dev/null; >> >> Tools with a similar interface: grep >> >> [...] > > It doesn't make sense to add something like -q/--quiet/--silent to > every single program, when equivalent behavior can be obtained at > the shell level. > > See: http://harmful.cat-v.org/cat-v/unix_prog_design.pdf
Hi Anders, I've read that paper before, and I consider it to be a very important guideline, but yet I don't think this feature goes against the Unix philosophy. cat -v or -s completely change cat's features. Even more so do cat -vt or -ve. Apart from the code needed for parsing the option, only one line of code has been modified in the whole program: - for (i = 0; i <= nfiles; i++) + for (i = quiet; i <= nfiles; i++) This should be an indicative that tee was already the tool for the job. I don't think this needs to extend to other programs. A different approach would be to write a new program, possibly called `te', in reference that it does the same as tee, but less, with only one of its two outputs. But I don't think a line of code deserves a new program. And a different one would be to devise a shell extension to allow giving superuser permissions to the redirectors '>' and '>>'. But this would imply much more work. However, in terms of specificallity, it might make even more sense. And yet a different approach would be to use the redirection to /dev/null (i.e., the current status quo). This is the least ugly of the ways to do this right now, and in fact it's what I've been doing up until now. But it feels wrong, it feels like I'm hacking a program that's not designed for that purpose. I'm creating an output to just remove it immediately after. But I still prefer that to other options like invoking a subshell with 'cat > file'. If I'm doing only one thing, and especially a very common one such as writing to a file, I think I should use a single tool for that (such as a simple '>' when I don't need sudo). I consider this not a new feature for tee, but a simplification of one of the main uses of tee, which was already being used for that: writing from a pipeline to a file (a protected one, that is). More like grep coming out of sed. Or also pcregrep to allow searching for multi-line patterns easily. You can use 'sed -n /RE/p', but you use 'grep' (I guess). You use '... | sudo tee >/dev/null file', but you could use '... | sudo tee -q file'. It's not like this represents 1% of tee's usage. I'd say it represents more than 50%, at least for me. As for being incompatible with old OSes, well, for that reason no new options would ever be developed. As someone already pointed out, we already have Turing complete scripting languages, with which you can already do literally everything. No new feature is really "needed", but it still can be useful to add it. There's bash, which has many extensions that sh doesn't have. And they're not really needed, but it's easier to write bash sometimes. It depends on the context. Yes, the week after merging this feature (if it is ever merged) there will be few systems with it, and you could maybe use it on the command line if you have it, but not much more. With time, it may spread across Unix systems, and maybe 30 years from now you will be able to use it on most systems. If you need to support a large range of systems you won't use the feature, as well as you wouldn't use bash extensions for the same reason. But some people use them, because in some contexts they make sense. Thanks, Alex -- Alejandro Colomar Linux man-pages comaintainer; https://www.kernel.org/doc/man-pages/ http://www.alejandro-colomar.es/
