Yes:

    read EP, $in, 2;
    $rec_len = unpack ("S>", $in);
[download]

But whether that is the right output will depend upon what you got sent.

This would also produce the same output on either type of machine:

    read EP, $in, 2;
    $rec_len = unpack ("S<", $in);
[download]

But which of those would produce the correct output, depend entirely on whether the data was packed in little or big-endian order to start with.

And that cannot be determined by the receiver; it can only be assumed.

Since you are using the term "$rec_len", the perhaps significant thing here is what is called Network order.

The Internet Protocol defines big-endian as the standard network byte order used for all numeric values in the packet headers and by many higher level protocols and file formats that are designed for use over IP....other stuff about the socket API...

The internet wouldn't work if there weren't some standards for this stuff. Often communicating over the internet requires conversion from the little endian format to big endian (Intel is a major force!). Local file storage is usually done in the native way the platform most naturally uses.

This whole business gets really messy if you are transferring a file between different architectures -> you just have to know what it is that you are dealing with. Standards for floating point binary are problematic.

But often you do know - example if it is say a Microsoft .WAV file - it is little endian and there is a detailed spec that defines all this.

Anyway sorry there is no "one size fits all" that can be universally discovered on the "fly". I should note that if you are defining the protocol, converting to an ascii representation within a file is "thinkable" if the performance hit is not a problem.

Welcome semiconPERL,

I'm going to guess that your problem is more about transferring data from big to little endian and vice-versa. One method I use is to convert the data to printable hex which is in network order. See the below code (tested):

#!/usr/local/bin/perl -w

my $data = "";
for (0..255) { $data .= chr($_); }  ## All possible byte combinations
open ( my $out, ">", "./testdata" ) or die "$!\n";
my $hdata = unpack("H*",$data);
print $out "$hdata\n";
close $out;

open ( my $in, "<", "./testdata" ) or die "$!\n";

my $sz = read( $in, my $new, 256 );
chomp( $new );
close $in;

my $ndata = pack("H*",$new);
# print "$hdata\n\n$new\n\n"; 

if ( $ndata eq $data ) { print "1. Okay\n"; }
if ( $hdata eq $new ) { print "2. Okay\n"; }
exit;

1;
[download]

  my $S16bits = substr($new, 0, 4, "" );   ## 4 bytes printable hex

     or

  my $S16bits = substr($ndata, 0, 2, "" );   ## 2 bytes hex data
[download]

Good Luck

If you control both ends, either use the alread mentioned "S>" or "S<" or the network versions "n" and "v" (see perldoc -f pack).

    s  A signed short (16-bit) value.
    S  An unsigned short value.
    n  An unsigned short (16-bit) in "network" (big-endian) order.
    v  An unsigned short (16-bit) in "VAX" (little-endian) order.
[download]

I made an overview of those pack results here for one of my talks.