[GRASS-dev] Re: [GRASS-SVN] r30420 - grass/trunk/scripts/v.db.renamecol

[Maciej Sieczka]

 >> Markus wrote:
 > Maciek wrote:
Hamish pisze:

>>> are you sure that this is portable?
>>>
>>> if [ "$driver" = "dbf" ] ; then
>>> -  NAMELEN=`echo "$newcol" | wc -c | awk '{print $1}'`
>>> +  NAMELEN=`echo "$newcol" | wc -c`
>>>
>>> I darkly remember that some "wc" programs insert odd spaces which
>>> would break the script.

>> I haven't heard of it. Maybe you are right. Let's ask on the dev ML. 
>> Thoughts, Anybody?

> 'wc -c filename' will produce output like: '17 filename' (needing awk
> or cut) while 'wc -c < filename' or 'cat filename | wc -c' will produce
> output like: '17'. Maybe that is the dark memory?

That could explain the " awk '{print $1}' ". Markus?

> For curiosity, what's so bad about using awk?

Invoking the allmighty awk just to do what cut is designed for seems an 
overkill to me. Awk is not needed for anything in v.db.renamecol. Cut 
suffices. Keep it simple, the UNIX way of specialized tools and stuff.

> speed?

Actually cut itself seems slightly slower than awk for this sort of task:

$ x=0; time while [ $x -lt 1000 ]; do echo "raz dwa" | cut -d" " -f2 > 
/dev/null ; x=`expr $x + 1`; done

on my machine is about 7% slower than

$ x=0; time while [ $x -lt 1000 ]; do echo "raz dwa" | awk '{print $2}' 
 > /dev/null ; x=`expr $x + 1`; done


On the other hand, after replacing all awk with cut in the script, 
removing the test for awk's presence:

#### check if we have awk
if [ ! -x "`which awk`" ] ; then
     g.message -e "awk required, please install awk or gawk first"
     exit 1
fi

resulted in a speed boost. In the end, v.db.renamcol without awk is as 
fast as it was with awk. I you want to test, try the following:

$ v.random pts n=10 --o; v.db.addtable pts col="huha1 integer
$ x=0; time while [ $x -lt 50 ]; do v.db.renamecol map=pts 
col=huha1,huha2; v.db.renamecol map=pts col=huha2,huha1; x=`expr $x + 
1`; done

using v.db.renamecol as it was with awk, and with all of awk removed or 
replaced by cut.

> It cannot be removed from all scripts* so why remove from any?  [*] needed for FP
> math (and less hard to find than bc), fancy stuff like v.in.mapgen,  ...

I know it is used widely in GRASS scripts. Yet there is no reason to 
require it in a script which does not need it (for instance unless there 
is FP maths in v.db.renamecol).

>  #### setup temporary file
>  TMP="`g.tempfile pid=$$`"
>  if [ $? -ne 0 ] || [ -z "$TMP" ] ; then
> -    g.message -e "Unable to create temporary files" 
> +    g.message -e "Unable to create temporary files."
>      exit 1
>  fi
> 
> IIUC the message standardization has been to not end single sentence
> warnings and errors with a ".", only to do that with module
> descriptions. (I don't know if I agree with that all the time, but a
> lot of effort has gone in to making it that way)

A sentence without a period? Strange and not grammatical. What would be 
the rationalle?

Even if it was agreed, I can't find it documented in SUBMITTING, 
SUBMITTING_SCRIPTS nor g.message man. Actually, the SUBMITTING_SCRIPTS 
examples indirectly suggest that both with and without period are 
allowed (see section 11).

The WIKI confirms the latter: "Be consistent with periods. Either end 
all phrases with a period or none", "Punctuated events, such as errors, 
deserve a period" [1]. This is contrary to what you suggest in your 
email now.

FWIW, the original v.db.renamecol used both conventions - with and 
without ".". I added periods to all sentences - correct in terms of 
grammar and GRASS standards I guess.

>  if [ -z "$table" ] ; then
> -   g.message 'There is no table connected to this map! Cannot rename
> any column.'
> +   g.message -e "There is no table connected to input vector map!
> Cannot rename any column."
>     cleanup
>     exit 1
>  fi
> 
> and r30418: v.db.dropcol
> @@ -91,5 +80,5 @@
>  exitprocedure()
>  {
> - g.message -e 'User break!'
> + g.message -e "User break!"
>   cleanup
>   exit 1
> 
> "!" is a special shell char and must be quoted in 'single quotes'.
> 
> GRASS> g.message -e "this will not work!, ok?"
> bash: !,: event not found

My bad. Very sorry. Correcting it right away.

Maciek

[1]http://grass.gdf-hannover.de/wiki/Development_Specs#Standard_messages_sandbox