>> 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