2

I have the following:

echo "PLATFORM = $PLATFORM"
DATE_STRING=`date +"20%y-%m-%d"`
echo "DATE_STRING = $DATE_STRING"
# VERSION_LINE will be something like: '#define VERSION_STRING "1.2p2"'
VERSION_LINE=`grep "^#define VERSION_STRING" ../version.hpp`
#  - awk pulls the "1.2p2"
#  - tr deletes the surrounding quotes
VERSION_STRING=`echo "$VERSION_LINE" | awk '{ print $3 }' | tr -d '"'`
echo "VERSION_STRING = $VERSION_STRING"
echo "####### Creating Archive ###########"
BINARY_FILE="build${PLATFORM}-${VERSION_STRING}-${DATE_STRING}_CLXXXXXXXX.zip"
echo "BINARY_FILE is $BINARY_FILE"

The output is

PLATFORM = Linux64
DATE_STRING = 2015-10-31
VERSION_STRING = 1.2p2
####### Creating Archive ###########
-2015-10-31_CLXXXXXXXX.zip4-1.2p2

All the inputs to the expansion of BINARY_FILE look right to me, but the result is mucked up. I've run into this several years ago, but can never recall what causes it. Any ideas? Thanks!

Tim
  • 153
  • i would guess it is a return character in your $VERSION_LINE pulled out of .hpp by grep. run ./yourscript | sed -n l – mikeserv Oct 31 '15 at 21:13
  • Wouldn't awk extract just my field? – Tim Oct 31 '15 at 21:22
  • 2
    dunno. is there a \return at the end of the line? is the field at the end of the line? even if im wrong about where it comes from or what it is, there is almost definitely something non-printable in there mucking about with the terminal display. run that command above to get a feel for what it is. by the way, it could very well be echo screwing with your output as well. a UNIX-standards-compliant echo will interpret C-style escapes in its arguments. – mikeserv Oct 31 '15 at 21:25
  • Yep. Right on. It was a \r somewhere the string. Can you post that as an answer so I can accept it? (Cut and past the above with "there is most likely ... ) – Tim Oct 31 '15 at 21:34

1 Answers1

5

There is almost definitely something non-printable in there mucking about with the terminal display, and I have a hunch it is a \return character fetched out of ../version.hpp by grep into $VERSION_LINE and from thence by awk into $VERSION_STRING. I could be wrong, but you should run:

./yourscript | sed -n l

...to get a feel for whatever it is.

By the way, it could very well be echo screwing with your output as well. A UNIX-standards-compliant echo will interpret C-style escapes in its arguments.

mikeserv
  • 58,310
  • 1
    piping to cat -v or cat -A is a good way of finding carriage-returns and other control-codes in output. – cas Oct 31 '15 at 22:52
  • @cas - possibly, but sed -n l is at least as good, and it is portable. – mikeserv Oct 31 '15 at 22:52
  • cat -A is GNU. cat -v and -t are portable. – cas Oct 31 '15 at 22:54
  • @cas - to linux and some bsds, yeah, probably. sed's l is POSIX. the only option POSIX spec's for cat is -u. another nice thing about it is the output format is also reliably specified. – mikeserv Oct 31 '15 at 22:55
  • @BinaryZebra - that doesn't give you a line-by-line view, exactly. also, without -v it squeezes consecutive sequences of input. and i dunno why you would do hex to find a \return or other non-printable: od -vtc <in. anyway, both sed and od are discussed in the linked answer. – mikeserv Nov 01 '15 at 00:27
  • @BinaryZebra - well, you definitely need an address if you don't use -v because otherwise there is no way of knowing how much input is squeezed for each * - which is specified behavior according to POSIX. printf %0512s | od. and even w/ -v, considering a conformant od writes output at 16-bytes (or some multiple thereof) per line rather than on a line-by-line basis it can be very easy to lose track of how its output relates to input anyway, and so an address is equally useful. still, if you like hex: od -vtc -vtx1 will do both simultaneously - which is also a reason for an address – mikeserv Nov 01 '15 at 00:41
  • That is what I wrote: od -tcx1. For short strings works fine: printf "hello" | od -tcx1. Adding a -v makes it printf "hello" | od -vtcx1. The adress could be removed (if needed). But again, all that is POSIX valid. –  Nov 01 '15 at 01:20
  • @BinaryZebra - except you need a -t for each, i think. i could be wrong. – mikeserv Nov 01 '15 at 01:38