On Mai 29 2020, Yuan Cao wrote:
> It just feels strange because the order does not reflect the order of the
> characters in the file.
But that's not true. It reflects exactly how 2-byte numbers are stored
in memory on your system. If you want to make a connection with
characters, you need to
Yuan Cao wrote:
> > https://www.gnu.org/software/coreutils/faq/coreutils-faq.html#The-_0027od-_002dx_0027-command-prints-bytes-in-the-wrong-order_002e
>
> Thanks for pointing me to this documentation.
>
> It just feels strange because the order does not reflect the order of the
> characters in
On Fri, May 29, 2020 at 1:20 AM Bob Proulx wrote:
> A little more information.
>
> Pádraig Brady wrote:
> > Yuan Cao wrote:
> > > I recently came across the following behavior.
> > >
> > > When using "--traditional x2" or "-x" option, it seems the order of hex
> > > code output for the
A little more information.
Pádraig Brady wrote:
> Yuan Cao wrote:
> > I recently came across the following behavior.
> >
> > When using "--traditional x2" or "-x" option, it seems the order of hex
> > code output for the characters is pairwise reversed (if that's the correct
> > way of
tag 41518 notabug
close 41518
stop
response below...
On 25/05/2020 04:05, Yuan Cao wrote:
Hello,
I recently came across the following behavior.
When using "--traditional x2" or "-x" option, it seems the order of hex
code output for the characters is pairwise reversed (if that's the correct
Hello,
I recently came across the following behavior.
When using "--traditional x2" or "-x" option, it seems the order of hex
code output for the characters is pairwise reversed (if that's the correct
way of describing it).
For example, using "od -cx" on a test file that contains "123456789\n",
