Here's a whacky idea; in a shell script I want to convert every line of stderr into a . on the same line. I'm still a shell scripting newbie but I know that bash can be quite powerful if you know what you're doing to it.

To begin with I've written a little wrapper on cvs commit called ~/bin/cvs_commit which does the following:

cvs commit -m "$1" | grep -v '\.bak*' | grep -v '\.pyc'

Because cvs prints all folders it recursively traverses I if it's a big tree all of that ugly stuff is print to screen via stderr. To get rid of that, I've changed my command to:

cvs commit -m "$1" 2>> /dev/null \
| grep -v '\.bak*' | grep -v '\.pyc'

Let's improve even more...

When you do a svn commit -m "" you get lots of little dots being printed slowly like this:

$ svn commit -m ""
Sending        OCH/sqlprofiling-och.log
Transmitting file data ...

I like that. To be able to do too I was thinking that one could redirect every line of stderr through a function that converts it to . without a linebreak and the lastly redirects it back out to stdout.

How? Can anybody help me??


Brock Noland

I can probaly help you, but I am not exactly sure what you want as I don't use cvs. Can you give an example what you want it to look like?


function linestodots() { while read f ; do builtin echo -n . ; done ; }

ls | linestodots
and here is a version which limits the number of dots printed on one line.
function linestodots()
local n=0;
local maxcols=79;
while read f ; do
let n++;
if [ $n -le $maxcols ] ; then
builtin echo -n . ;
if [ $n -gt 0 ] ; then
this just uses the stdout lines as input, not stderr.
I do not believe it is possible to redirect just stderr to a pipe except by
using 2>&1 and then redirecing stdout using >.
either way you wouldn't get the stdout
output on the screen.'

you could pipe both stdin and stout through and then modify the function to only do dots for lines which match those that are the file names.


I have to disagree with Chris above, stderr can be redirected on its own without any problem.

Your email will never ever be published.

Related posts