-={ lundi, 06 juin 2016, 08:12:57 +0000 }=-

Hey Red!

Type 2 pkt header has 18 fields, the most interesting being the last which
contains 20 ascii nulls - as if there aren't already too many nulls some of
which are supposed to be delimiters.  That insanity aside, a simple 'tail -c
20 <<< $pktHeader | tr -d \0' call will only produce output if indeed the
$pktHeader (the first 58 bytes of a raw pkt) is not the so-called 'fill'
field.  If it is then a not call (!) to 'if' will reveal a type 2 pkt header.

  if [ ! "$(tail -c 20 <<< $pktHeader | tr -d \0)" ]; then
    echo "Type 2 pkt header"
  fi

A type 2.2 pkt header - which is clearly the winner for cutting down cpu
cycles and producing the least amount of useless output - has an eight byte
fill field (ascii nulls) at offset 8 (zero based) and following the same logic
as the type 2 then this does work;

  if [ ! "$(cut -c 9-16 <<< $pktHeader | tr -d \0)" ]; then
    echo "Type 2.2 pkt header"
  fi

Note that 'cut' and counts the first byte as 1 instead of 0, thus the '-c
9-16' part.

As for type 2+, I don't see anything unique other than to say if it fails the
type 2 and 2.2 tests then it must be a type 2+.

A purely bash-ist idea for those that might believe that fidonet pkt headers
have something in them worth jumping through hoops for.  This sysop thinks not
but had some fun toying around with the idea and thought it might be fruitful
to someone.  Probably not but what the heck.

Life is good,
Maurice

... Don't cry for me I have vi.
--- GNU bash, version 4.3.42(1)-release (x86_64-atom-linux-gnu)
 * Origin: Little Mikey's Brain - Ladysmith BC, Canada (1:153/7001.0)