[Gllug] Awk Sed

[Alex Hudson]

On Sat, 2001-12-08 at 20:17, Colin Coles wrote:
> > If you took the comment the way it was meant, I wasn't berating you, I
> > was _warning_ you.
> 
> Sounded more like lampooning the author because you didn't like his coding 
> style to me.

I don't like his coding style ;) Programming is _entirely_ a matter of
style - don't let "engineers" tell you otherwise.

> > That script will eat files. If you use the 'from file' function, you'd
> > better make sure that it's character-perfect. A mis-placed ' ' on the
> > end of a line and the script will start in / and keep going until it's
> 
> This simply isn't true, there are regex's that deal with this.

No, you're wrong. Examine the code:

if($dirpath eq ""){$dirpath = '.';}
$dirpath =~ s/\s//g;
if($dirpath !~ /(\/)$/){$dirpath .= '/';}

So, set it to '.' if it's not specified. Remove the space from it. Pop a
'/' on the end if it doesn't have one already. Let's say your replace
file contains:

"Teh^^The^^ "

(without quotes). Putting ' ' in dirpath means that it gets changed to
'/' (run it through the code above). 

In my opinion, what is _worse_ is this issue in an interactive session -
_no_ checking happens to interactive input, so if you accidentally press
return before entering the directory you want to check (perhaps they key
sticks, for example) it _again_ assumes a start directory of /!! I
_really_ think that is dangerous - it makes it completely unsuitable for
running as root, which a tool of this sort shouldn't be - a one-line
perl -pi, for example, is far safer.

Running the program, pressing Enter twice and then dot-Enter also
corrupts files (shurely should be s///g;, which would be harmless, but
apparently isn't because it doesn't chomp <STDIN>;)

There's just so many ways to get it wrong accidentally.

> OK, fair enough people are stupid, have hangovers etc. it is a powerful tool 
> and should be used with similar respect afforded to other powerfull tools. 
> But if someone where to enter /dev as the search directory perhaps they 
> shouldn't be left on their own, no different to rm -Rf really. Perhaps you 
> have a different view of the intelligence of Linux users than me.

My point was, if you're on a fast machine and the script assumes '/' as
a starting directory, it's going to get to /dev in short order. There's
powerful (as in chainsaws) and there's ridiculous (as in chainsaws that
turn on and off at random). I also personally don't believe Linux users
to be any more or less intelligent that any other set of users, but
again that's opinion...

> One mans problem is another mans opportunity. The beauty of this OS is its 
> configurability, with that comes danger, surely you must expect to meet these 
> two in fairly equal proportions.

I don't buy configurability==danger, that's rubbish. 

> Perhaps this could be improved, but how much hand-holding do you want?

If the config file contains:

Teh^^the^.

.. I expect it to warn the user, because the instructions are clearly
wrong. It doesn't. I could list a number of such examples. I really
don't understand why people think that the command line shouldn't be
easy to use.

> I'm sure you wouldn't prefer the 
> Microsoft way, or is there a third way?

I don't expect the computer to make decisions for me, unless I ask.
However, I expect it to offer help, and tell me when I'm doing something
wrong. Computers are here to help, not serve dumbly.

> I don't think that this makes you a bigot but then it's not the crux of your 
> last message. The script does exactly what it says on tin, not my idea of 
> crap :)

Outlook allows active scripting in e-mail. It even says it does that,
it's a feature. That doesn't make it good ;)

Goodness/badness isn't just a matter of whether or not the program
mostly works; I rate collateral damage fairly high in the badness
stakes. 

Cheers,

Alex.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 240 bytes
Desc: not available
URL: <http://mailman.lug.org.uk/pipermail/gllug/attachments/20011208/2142c9c3/attachment.pgp>