[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: OT: automation

From: olafBuddenhagen
Subject: Re: OT: automation
Date: Fri, 6 Nov 2009 09:22:14 +0100
User-agent: Mutt/1.5.19 (2009-01-05)


On Wed, Nov 04, 2009 at 09:54:29PM +0100, Arne Babenhauserheide wrote:
> Am Sonntag, 1. November 2009 11:54:28 schrieb olafBuddenhagen@gmx.net:

> > Another variant is zmv, which is part of zsh. I comes with its whole
> > own language for specifying non-trivial filename patterns... Which
> > is just idiocy. People would be much better off spending the time on
> > learning generic for and sed instead, which comes in handy in other
> > situations as well, instead of a single-purpose language only for
> > this.
> At least I know now what people mean with "powerful zsh" :) 

It is one of the reasons why I dislike zsh: it has a lot more features
than say bash -- and almost all of them are things that don't belong in
the shell in the first place...

> > So you want:
> > 
> >    find -type f -print0|xargs -0 -L 1 echo sed -i 's/orig/new/'
> -L is what I searched for hours - many times now - but I never knew
> exactly how to search for it... 

This is the kind of stuff you get better chances to get on with by
asking people directly, e.g. on IRC... There is a well-populated #bash
channel on freenode (I never went there though...); and #gnu also tends
to have a few people more or less experienced with the shell. (The
overall S/N ration in the latter is very poor though :-( )

> It saves me from find | sed s/^/\"/ | sed s/$/\"/ | xargs 

You could write this more elegantly as:

   find|sed -e 's/^/"/' -e 's/$/"/'|xargs


   find|sed 's/^/"/;s/$/"/'|xargs

or better (more compact):

   find|sed 's/^\|$/"/g'|xargs

or a bit clearer:

   find|sed 's/.*/"&"/'|xargs

or leave out the sed alltogether and do:

   find -printf '"%p"\n'|xargs

or alternatively (same effect I think, but less efficient):

   find -exec ls -Q '{}' ';'|xargs

or yet better (much safer):

   find -exec ls --quoting-style=shell '{}' ';'|xargs

Note though that xargs -L does something completely different -- I think
you got confused there. The Right (TM) alternative is simply:

   find -print0|xargs -0

This is both simpler, and also more robust than all of the above
variations (except perhaps for the last) -- I only listed them for
general ideas that could be useful in a different context :-)

> > Where does escaping come in here at all?... (Unless you mean the
> > actual sed script, which is usually a constant string, and it's
> > generally a good idea to put it in single quotes -- I never even
> > considered leaving these out...)
> I mean stuff like this: 
>       sed 's/blah\\\\/blubb/blau/'
> (I didn't know that I can just enclose the whole 's///' in quotes -
> but now that I see it, it's clear - it's just an argument)

Yeah, escaping in sed script can get really messy when not quoting the
whole argument... I just wonder where you learned such an unfortunate
practice :-)

BTW, usually there is no need to escape slashes in sed scripts at all --
you could just do (for example):

   sed 's#blah/blubb#blau#'

(You can choose any character you like for the delimiter.)

> > Of course there are other situations where escaping is indeed
> > necessary. However, most of the time it boils down to learning to
> > use "$i" instead of bare $i:
> > 
> >    for i in *; do mv "$i" `<<<"$i" sed 's/\.JPG$/\.jpeg$/'`; done
> > 
> > I agree though that quoting is the single most problematic issue in
> > shell scripting.
> What do the <<< do in there? 

That indicates a "here string" -- the token following it will be used as
stdin of the command. Same effect as:

   echo "$i"|sed

> > Of course you can teach a writer to use text files, because text
> > files are more powerful -- but they are only more powerful if you
> > also teach him the stuff which can actually deal better with text
> > files... Which is shell scripting.
> And version tracking and website creation. 
> That's one thing I had to manage for my free roleplaying system. Get
> every contributor to write txt or at least rtf but not Open Document
> files, which are terrible to version (why did they have to split the
> data into several files when they use XML anyway?). 

Indeed, ODF is a pain. Note though that it would be possible to write
some plugins/scripts or perhaps even just commit hooks for the VCS to
transparently unzip the archive and do diff etc. on the XML files --
however, diffing and merging the XML would still be of pretty limited
value I fear...

> > > It's far less versatile than the shell, but it does what he needs
> > > and he doesn't have to spend as much time learning things he won't
> > > really need (improving ones writing skills takes enough learning
> > > time).
> > 
> > I don't buy this kind of arguments. Most people nowadays spend *a
> > lot* of their time working with computers: many hours a day. And
> > every regular computer user will need to do some less common stuff
> > now and then. Some shell scripting skills will always pay off.
> Most computer users nowadays never enter a shell - and never means
> never, because they don't even know they have a shell. 

Yeah, that's an unfortunate situation, which we should try to rectify

(Admittedly, it would be much easier if shells were more "welcoming" and
better integrated with the GUI stuff... Another thing I still need to
write about. In fact, that's at the very core of my user interface


reply via email to

[Prev in Thread] Current Thread [Next in Thread]