Re: [Help-bash] Reading and handling "control" characters from a file

[Conrad J. Sabatier]

On Sun, 22 Apr 2012 00:50:25 +0200
Davide Brini <address@hidden> wrote:

> On Sat, 21 Apr 2012 14:13:52 -0400, Chet Ramey <address@hidden>
> wrote:
> 
> > On 4/19/12 6:11 PM, Conrad J. Sabatier wrote:
> > > I've just started doing a little prototyping in bash for a
> > > program I'll eventually code most likely in C, and have hit a
> > > serious stumbling block re: the handling of characters (bytes) in
> > > the very low range of the ASCII table.
> > 
> > Bash variables are strings of characters.  There is a difference
> > between a character with ASCII value 4 and a character with the
> > ASCII value 52 ("4").  Shell arithmetic convers the latter into
> > numbers using the equivalent of strtol() before use.
> > 
> > To make what you want work, you'll have to figure out some way to
> > offset the value you read from the file (i.e., c+'0') before
> > attempting to use it in an arithmetic context.  Maybe perl or
> > something like that could help. It's quite difficult to do using
> > just what the shell provides.
> 
> Shouldn't the single quote trick work here? eg
> 
> $ a=$(printf '\x4\n')
> $ printf "%d\n" "'$a"
> 4
> 

Yes, I thought that was the solution for a brief time, but it still
fails when the character is a newline, for some odd reason.  Bash seems
to be rather fickle when it comes to certain things, allowing this,
objecting to that.

As I mentioned in an earlier followup, I started using:

read -r -n 1
printf -v byte "%d" \'"${REPLY}"

This seemed, at first, to be the magic bullet I had been looking for.
At least it was accepting a lot more input and converting the raw bytes
to usable values, but it turns out there are still some exceptions,
such as the newline I just mentioned, which winds up as zero.

Most annoying.  Just seems so irregular, inconsistent, non-orthogonal
and unpredictable. 

-- 
Conrad J. Sabatier
address@hidden