From debbugs-submit-bounces@debbugs.gnu.org Mon May 25 01:55:21 2020 Received: (at submit) by debbugs.gnu.org; 25 May 2020 05:55:21 +0000 Received: from localhost ([127.0.0.1]:39513 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jd653-0007U7-6b for submit@debbugs.gnu.org; Mon, 25 May 2020 01:55:21 -0400 Received: from lists.gnu.org ([209.51.188.17]:37538) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jd3Qg-00019Q-TX for submit@debbugs.gnu.org; Sun, 24 May 2020 23:05:31 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:44396) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jd3Qg-00089G-Lm; Sun, 24 May 2020 23:05:30 -0400 Received: from mail-vs1-xe32.google.com ([2607:f8b0:4864:20::e32]:42203) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jd3Qf-0000gI-Ri; Sun, 24 May 2020 23:05:30 -0400 Received: by mail-vs1-xe32.google.com with SMTP id 1so9209559vsl.9; Sun, 24 May 2020 20:05:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=7FhxknWgI2/WoP7kWhw6UdT28uXBaQk+S0WCmUm02IY=; b=px9CoplPSkuDx1r7DWqjp7l8blaetnAZseE9E94mXEH9dKgD14DjgdLKEZinZkxDor sLAXvRpRP50x7T/nmIL7XdWX3H0LloW2BzucaLm8pi+6tCb+M2PsShCakPqhFST971K5 +hjkL5eJ3lhxfFLB4hGk2DCW6t5op8VbQme59GTIU+1to+nfkNop+6HeGuDJD94ZpSos UhXcJj+v1pHAdHmcvw+DejJ6S8LSG8KxvNhY85xBhNPWqyTVpuhkvWmkvhyy78Gg9QNm PvF2PWLS96FekoQM/BGK+5pi4Qtt12tlwaIMmwfRx2Hk6kFcx+1h27LwdNt32xhjPcjD 6nMg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=7FhxknWgI2/WoP7kWhw6UdT28uXBaQk+S0WCmUm02IY=; b=knu3X8RLAb5OT+TlZZu0ySX7M9Oc0+qTNFweOZHdnP0ROSzgpVcY9LeMFd69DFDGOB JX6bCiCv2IZQ3gKMwK/MZ9ImMMzG/ATCuRqehfuaz0Hxl7MAvh0JGmomLSAQArBijIPe mwkv1uAA2ZZck/aFSmJ9Otj1x5pCKOcmqdng72Pna4M7GFF+hifDQbf0YF3I34WDkHdl uNaBruN6wFJnHb5kPiThfjniZQS1AwixS6ktGoMUkHKjzm5s6cjrJilpia0a57owRt4O QAXII+v6JxzSkKhlU330XG2eefbWwYiOcF/fOoF7R1qeKLhPVNi7MmbHWuPX3w5gngqC dY9A== X-Gm-Message-State: AOAM530ANX9Uu4lcp6FXR/2I5bslx71IwRILJXTuieq2wi4oriAkXjSG CPVzO867OPnvOO5po/RWB66vX85juhpRc3dUIO/gfNrZ X-Google-Smtp-Source: ABdhPJzq+HQJ6SFrWQzcXDsvqYg4qEWu5KeAOTcNOi+GR+Z1AAo24kBMuCmIohHZHR/m9VjdLxoacPFAsJ5N6r0yM2Y= X-Received: by 2002:a67:8d48:: with SMTP id p69mr2052555vsd.86.1590375927604; Sun, 24 May 2020 20:05:27 -0700 (PDT) MIME-Version: 1.0 From: Yuan Cao Date: Sun, 24 May 2020 23:05:16 -0400 Message-ID: Subject: Bug in od? To: coreutils@gnu.org, bug-coreutils@gnu.org Content-Type: multipart/alternative; boundary="000000000000396a6b05a67040a1" Received-SPF: pass client-ip=2607:f8b0:4864:20::e32; envelope-from=yuancao85@gmail.com; helo=mail-vs1-xe32.google.com X-detected-operating-system: by eggs.gnu.org: No matching host in p0f cache. That's all we know. X-Spam_score_int: -17 X-Spam_score: -1.8 X-Spam_bar: - X-Spam_report: (-1.8 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001 autolearn=_AUTOLEARN X-Spam_action: no action X-Spam-Score: 0.9 (/) X-Debbugs-Envelope-To: submit X-Mailman-Approved-At: Mon, 25 May 2020 01:55:20 -0400 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.1 (--) --000000000000396a6b05a67040a1 Content-Type: text/plain; charset="UTF-8" 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", you get the following output: 0000000 1 2 3 4 5 6 7 8 9 0 \n 3231 3433 3635 3837 3039 000a 0000013 It seems like it should be the following instead: 0000000 1 2 3 4 5 6 7 8 9 0 \n 3132 3334 3536 3738 3930 0a00 0000013 The version involved is od in GNU coreutils 8.28. Best Regards, Yuan --000000000000396a6b05a67040a1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello,

I recently came across the follo= wing behavior.

When using "--traditional= x2" or "-x" option, it seems the order of hex code output f= or the characters is pairwise reversed (if that's the correct way of de= scribing it).

For example, using "od -cx"= ; on a test file that contains "123456789\n", you get the followi= ng output:

0000000 =C2=A0 1 =C2=A0 2 =C2=A0 3 =C2= =A0 4 =C2=A0 5 =C2=A0 6 =C2=A0 7 =C2=A0 8 =C2=A0 9 =C2=A0 0 =C2=A0\n
=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A03231=C2=A0 3433= =C2=A0 3635=C2=A0 3837=C2=A0 3039=C2=A0 000a
0000013

It seems like it should be the following instead:

0000000 =C2=A0 1 =C2=A0 2 =C2=A0 3 =C2=A0 4 =C2=A0 5 =C2=A0 6 =C2=A0 = 7 =C2=A0 8 =C2=A0 9 =C2=A0 0 =C2=A0\n
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A03132=C2=A0 3334=C2=A0 3536=C2=A0 3738=C2=A0 393= 0=C2=A0 0a00
0000013

The version involved is od= in GNU coreutils 8.28.

Best Regards,
<= div>
Yuan
--000000000000396a6b05a67040a1-- From debbugs-submit-bounces@debbugs.gnu.org Mon May 25 06:48:35 2020 Received: (at 41518) by debbugs.gnu.org; 25 May 2020 10:48:35 +0000 Received: from localhost ([127.0.0.1]:39930 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jdAel-0008Si-CG for submit@debbugs.gnu.org; Mon, 25 May 2020 06:48:35 -0400 Received: from mail-ed1-f67.google.com ([209.85.208.67]:36730) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jdAej-0008SQ-5S; Mon, 25 May 2020 06:48:29 -0400 Received: by mail-ed1-f67.google.com with SMTP id b91so14668241edf.3; Mon, 25 May 2020 03:48:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=8+z7mcKvojGk7JDZWLQokJZJAkIaX5mvkq7cKspdoHU=; b=NtkZjs4uq81TSqdttjoMmp8nnFO2eGtHBcaJ+75Q86Ur5sdsifLO4qv1wu9TBapmLQ g3FCPm1RelW5ljV33EkJXmvKt9BSrS09hiiF8Q+Lcoi7CZTPZ9o15ZvS9qXpcAAclQzx 8Oex99eZHeUxFHvwZD2nvIQ8NWJ5T0l19hjTXUljiBwl3AXyg26082OsSqDEIq6/AzRz RMC+kzvzBgOp04T9kY2WZf86Fpn2Zxhy1wqcdqEgmnWrGJc5mZPpxtpLVkTlZPP837l0 ZQ7U09jndNxeFgPyxRrWRWQXPxjYUj/LIkivdkTYKex3mUekNzhLg39oIlI0XyPUCkxx u7mA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=8+z7mcKvojGk7JDZWLQokJZJAkIaX5mvkq7cKspdoHU=; b=mTBQPWVtBt6HV8u+5Bij8jNFvWx7faQ/akvBAIMAztjo7toQxI6nqBEpPnTXrT4QZ9 IfAdhw2G9TnUYyisj3H/PDYXtIaDUiH5BkpCpRtas/P0IiWqbyRDctCrJr2CgU7JtC4t ZNkujZq3gpnzqcj+edH4gC/TuMHS/leQs21bqXVMPW7mFL40h9AP3G3332ZlKaP4rnyg Z4ul5zgGfAy1/6NskZXZRH1iasHig5bVqJqsMOxsC5QeYVCdCDzaMPdZEElk7R+bRXBG EcA7QM8nEqu/XSCxJuwVqjxFJ0let4OWecVBR1Wdjw3UH4ycvRVd3t60BzFm7dIFIUsx 7OKg== X-Gm-Message-State: AOAM5301Rju2tRZtSEc8oNeg32T6dHYlLLb57U4ReGC4bdLXdZYZJllk Bp+soZMzUQT1FnjYFxPUEQU3cSgS X-Google-Smtp-Source: ABdhPJwr+wmDgWNYcx0csaKB2p6VYP2YzvEts4BHzek+CL2nI3SfWja34eqGNLrhjXbv9ECP80/Ldw== X-Received: by 2002:aa7:d0d9:: with SMTP id u25mr13795522edo.377.1590403702978; Mon, 25 May 2020 03:48:22 -0700 (PDT) Received: from localhost.localdomain (86-42-14-227-dynamic.agg2.lod.rsl-rtd.eircom.net. [86.42.14.227]) by smtp.googlemail.com with ESMTPSA id 96sm10432913edq.56.2020.05.25.03.48.21 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 25 May 2020 03:48:22 -0700 (PDT) Subject: Re: bug#41518: Bug in od? To: Yuan Cao , coreutils@gnu.org, 41518@debbugs.gnu.org References: From: =?UTF-8?Q?P=c3=a1draig_Brady?= Message-ID: <4d278b06-eb27-e3d2-6e90-fd7d902d5af8@draigBrady.com> Date: Mon, 25 May 2020 11:48:20 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:76.0) Gecko/20100101 Thunderbird/76.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Score: 0.5 (/) X-Debbugs-Envelope-To: 41518 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.5 (/) 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 > way of describing it). > > For example, using "od -cx" on a test file that contains "123456789\n", you > get the following output: > > 0000000 1 2 3 4 5 6 7 8 9 0 \n > 3231 3433 3635 3837 3039 000a > 0000013 > > It seems like it should be the following instead: > > 0000000 1 2 3 4 5 6 7 8 9 0 \n > 3132 3334 3536 3738 3930 0a00 > 0000013 > > The version involved is od in GNU coreutils 8.28. That's because you're on a little endian machine. If you want to reorder as per a big endian machine you can: od --endian=big -cx your_file If you want to hexdump independently of endianess you can: od -Ax -tx1z -v cheers, Pádraig From debbugs-submit-bounces@debbugs.gnu.org Fri May 29 01:20:50 2020 Received: (at 41518) by debbugs.gnu.org; 29 May 2020 05:20:50 +0000 Received: from localhost ([127.0.0.1]:53578 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jeXRq-0005X4-1s for submit@debbugs.gnu.org; Fri, 29 May 2020 01:20:50 -0400 Received: from havoc.proulx.com ([96.88.95.61]:58232) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jeXRo-0005Wq-94 for 41518@debbugs.gnu.org; Fri, 29 May 2020 01:20:48 -0400 Received: from joseki.proulx.com (localhost [127.0.0.1]) by havoc.proulx.com (Postfix) with ESMTP id CE45A4FA; Thu, 28 May 2020 23:20:41 -0600 (MDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proulx.com; s=dkim2048; t=1590729641; bh=lkSoxMAxO9F/ZzhI2W2WMhgBGWaJ5naHUtZfHLXazPo=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=JrFj5pPgbnXLfGF6sPJ6n9alit6d6YkKyZNu1kjkCBINNmC9pM3iDA55KiPxvqW+Z i/y3vQ7XewfadmdA9xLEh9PkypSAfKM6Q6Xx6jgCaPBnL+h5G5hkVJZ1BIgA8AuJRN O2vhiAX+oejyax2ZFiwfg/Iq37Kg6skg5GBjUSjvh0UKwWef5YnZ9pA9lpqBPVlT0q QEixIrK1iM7M2l2Vc08T3Bj8m65MiR0SdsxiuIGsrQYSxDdLZt/cxZb9vXj4keSXbJ qq5eMz0+XIO5xEiA4JgeJeorZGksrAMOrGQ418wQrf1P63sezquenV/FSCVwLUQFBT jgNQWruYoyYZg== Received: from hysteria.proulx.com (hysteria.proulx.com [192.168.230.119]) by joseki.proulx.com (Postfix) with ESMTP id 9EF902114D; Thu, 28 May 2020 23:20:41 -0600 (MDT) Received: by hysteria.proulx.com (Postfix, from userid 1000) id 8E6142DC8E; Thu, 28 May 2020 23:20:41 -0600 (MDT) Date: Thu, 28 May 2020 23:20:41 -0600 From: Bob Proulx To: Yuan Cao Subject: Re: bug#41518: Bug in od? Message-ID: <20200528231636675583879@bob.proulx.com> References: <4d278b06-eb27-e3d2-6e90-fd7d902d5af8@draigBrady.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <4d278b06-eb27-e3d2-6e90-fd7d902d5af8@draigBrady.com> X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 41518 Cc: 41518@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) 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 describing it). ‘-x’ Output as hexadecimal two-byte units. Equivalent to ‘-t x2’. Outputs 16-bit integers in the *native byte order* of the machine. Which may be either big-endian or little-endian depending on the machine. Not portable. Depends upon the machine it is run upon. > If you want to hexdump independently of endianess you can: > > od -Ax -tx1z -v The -tx1 option above is portable because it outputs 1-byte units instead of 2-byte units which is independent of endianess. This is the FAQ entry for this topic. https://www.gnu.org/software/coreutils/faq/coreutils-faq.html#The-_0027od-_002dx_0027-command-prints-bytes-in-the-wrong-order_002e Bob From debbugs-submit-bounces@debbugs.gnu.org Fri May 29 16:47:37 2020 Received: (at 41518) by debbugs.gnu.org; 29 May 2020 20:47:37 +0000 Received: from localhost ([127.0.0.1]:56328 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jelui-0006nS-Ur for submit@debbugs.gnu.org; Fri, 29 May 2020 16:47:37 -0400 Received: from mail-ua1-f42.google.com ([209.85.222.42]:39857) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jelug-0006nF-Pi for 41518@debbugs.gnu.org; Fri, 29 May 2020 16:47:35 -0400 Received: by mail-ua1-f42.google.com with SMTP id z12so1269419uap.6 for <41518@debbugs.gnu.org>; Fri, 29 May 2020 13:47:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Ys+ARrlgKPHxn8wp+/vb/n+30p8cV3y6LmbbHVa7uDo=; b=jUUFKZqRO3YksFHuw70BFq5qAK9SBFpv98yqMK86r4JNs+K+21diOsU9mj/7hcz+MI EefVtsDHRdmsVKGDLlP+ZGRHkLqViTiAgUtcoJgCRPMq4hIHB1q2ws0Dq7Lzjpa/EKmy dHQOY3BEvd3k7HmWKC5nS1EjJFWkDUcBu8AY0gbr5GFhqnBlepmv4c/hYF4l/LgpzSSa ZvBoD3GI+LJmRaV//JclhsCVWaFxMZ1iUPvAHQwBgnYS+4wYbPTuMOIYqVNXrXHfuoOm umtlWv97y4BJiwyDDRGJK9SDOCLFU5Vc8kko4rOd52DcJ1dk/slIdEx9L0/I3lzXdRIh ALgQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Ys+ARrlgKPHxn8wp+/vb/n+30p8cV3y6LmbbHVa7uDo=; b=YH5+gK1jfimKRSqYUZ9X2P6BdOLihXxyo03W6B16ngkIAlW53u1JAHwG9hk6DxnCHc VBEBRTNwbwgnL4L0Bb6ohhl3fJ1oQ/vZ+2U9AfHIwRELJe9JGjGwDpeO+zim3t76e44G zdmdfuoTYCC/R1rJbSthtUHwzx2o564edvge2BWIlbeKrm7KkU/tSYvu2AOTJx6mrsfG Lx7vbFXRSP4Cn6pu78XSljEH6Zj8iMOgM+H/kCFSHL0vmxd9EVD558VFyrt1WMXdpM9D 1GU1hQfmQJJsnjdFuRPX0BBGQR5SCXJu0kCUlwqgb9teydePMyDmCM/vLLRsTQA0Mz5s mwdA== X-Gm-Message-State: AOAM530L+d994E8VtCeD1OSkbBSNIqUwp0kTniK4+YLhwSni4C7Zkbvb sPvGJtXQiPSphI9O1m6ifnzVF7U4c4Ysh2pdwAuVNQ== X-Google-Smtp-Source: ABdhPJzmj6fiwjiOcTYMPNtCg3ImN1hwQl3INKmMfH7WQOIJTkMx2fxxP7PHjwh4iJpsl3QoMJW04+CZJnq3wn6sUtw= X-Received: by 2002:ab0:3ae:: with SMTP id 43mr7841801uau.25.1590785248971; Fri, 29 May 2020 13:47:28 -0700 (PDT) MIME-Version: 1.0 References: <4d278b06-eb27-e3d2-6e90-fd7d902d5af8@draigBrady.com> <20200528231636675583879@bob.proulx.com> In-Reply-To: <20200528231636675583879@bob.proulx.com> From: Yuan Cao Date: Fri, 29 May 2020 16:47:17 -0400 Message-ID: Subject: Re: bug#41518: Bug in od? To: Bob Proulx Content-Type: multipart/alternative; boundary="000000000000add06a05a6cf8db4" X-Spam-Score: 0.3 (/) X-Debbugs-Envelope-To: 41518 Cc: 41518@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) --000000000000add06a05a6cf8db4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, May 29, 2020 at 1:20 AM Bob Proulx wrote: > A little more information. > > P=C3=A1draig Brady wrote: > > Yuan Cao wrote: > > > I recently came across the following behavior. > > > > > > When using "--traditional x2" or "-x" option, it seems the order of h= ex > > > code output for the characters is pairwise reversed (if that's the > correct > > > way of describing it). > > =E2=80=98-x=E2=80=99 > Output as hexadecimal two-byte units. Equivalent to =E2=80=98-t x2= =E2=80=99. > > Outputs 16-bit integers in the *native byte order* of the machine. > Which may be either big-endian or little-endian depending on the > machine. Not portable. Depends upon the machine it is run upon. > > > If you want to hexdump independently of endianess you can: > > > > od -Ax -tx1z -v > > The -tx1 option above is portable because it outputs 1-byte units > instead of 2-byte units which is independent of endianess. > > This is the FAQ entry for this topic. > > > https://www.gnu.org/software/coreutils/faq/coreutils-faq.html#The-_0027od= -_002dx_0027-command-prints-bytes-in-the-wrong-order_002e > > Bob > Thanks for pointing me to this documentation. It just feels strange because the order does not reflect the order of the characters in the file. I think it might have been useful to get the "by word" value of the file if you are working with a binary file historically. One might have stored some data as a list of shorts. Then, we can easily view the data using "od -x data_file_name". Since memory is so cheap now, people are probably using just using chars for text, and 4 byte ints or 8 byte ints where they used to use 2 byte ints (shorts) before. In this case, the "by word" order does not seem to me to be as useful and violates the principle of least astonishment needlessly. It might be interesting to change the option to print values by double word or quadword instead or add another option to let the users choose to print by double word or quadword if they want. Best Regards, Yuan --000000000000add06a05a6cf8db4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Fri, May 29, 2020 at 1:20 AM Bob P= roulx <bob@proulx.co= m> wrote:
A little more information.

P=C3=A1draig 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 describing it).

=E2=80=98-x=E2=80=99
=C2=A0 =C2=A0 =C2=A0Output as hexadecimal two-byte units.=C2=A0 Equivalent = to =E2=80=98-t x2=E2=80=99.

Outputs 16-bit integers in the *native byte order* of the machine.
Which may be either big-endian or little-endian depending on the
machine.=C2=A0 Not portable.=C2=A0 Depends upon the machine it is run upon.=

> If you want to hexdump independently of endianess you can:
>
>=C2=A0 =C2=A0od -Ax -tx1z -v

The -tx1 option above is portable because it outputs 1-byte units
instead of 2-byte units which is independent of endianess.

This is the FAQ entry for this topic.

=C2=A0 https://www.gnu.org/software/coreutils= /faq/coreutils-faq.html#The-_0027od-_002dx_0027-command-prints-bytes-in-the= -wrong-order_002e

Bob

Thanks for pointing me to this docu= mentation.

It just feels strange because the order= does not reflect the order of the characters in the file.

I think it might have been useful to get the "by word" v= alue of the file if you are working with a binary file historically. One mi= ght have stored some data as a list of shorts. Then, we can easily view the= data using "od -x data_file_name".

Sinc= e memory is so cheap now, people are probably using just using chars for te= xt, and 4 byte ints or 8 byte ints where they used to use 2 byte ints (shor= ts) before. In this case, the "by word" order does not seem to me= to be as useful and violates the principle of least astonishment needlessl= y.

It might be interesting to change the option to= print values by double word or quadword instead or add another option to l= et the users choose to print by double word or quadword if they want.
=

Best Regards,

Yuan=C2=A0
=
--000000000000add06a05a6cf8db4-- From debbugs-submit-bounces@debbugs.gnu.org Fri May 29 18:33:08 2020 Received: (at 41518) by debbugs.gnu.org; 29 May 2020 22:33:09 +0000 Received: from localhost ([127.0.0.1]:56439 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jenYq-0000vg-L7 for submit@debbugs.gnu.org; Fri, 29 May 2020 18:33:08 -0400 Received: from havoc.proulx.com ([96.88.95.61]:38994) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jenYf-0000v1-Bc for 41518@debbugs.gnu.org; Fri, 29 May 2020 18:33:08 -0400 Received: from joseki.proulx.com (localhost [127.0.0.1]) by havoc.proulx.com (Postfix) with ESMTP id 3CB8E1B6; Fri, 29 May 2020 16:32:51 -0600 (MDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proulx.com; s=dkim2048; t=1590791571; bh=lw+1CLeLLE4y7KfuhEDrlL2k4F+qWQy13jXsBQniBHU=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=SVGlvRPNWjJ60lyL2O8w4JTb3iTirlxmF68C8DfkpdvwSMi5mxFx4nRuX4rPkHqtj Qvi/vJCM4qHi2Zi1bvSb0zceSn51HuORK5fVsp2FsmCoQ43sMiDJF8TrUuEWzwvTYm rC68h+j7tSMTbKdIXsaOYg0/UjjN8tNwO1Jm/kK6qWhbeicttxeiAb73Z0xOac6Ord SyAR2HKXxHQ/bRLd+/hQlfIZuq7lnHsEl9ml3g8eqbGeITlnB5E/YpxLC0OexRMPgo dNj+4GuuMcwbwCjOf2DY5cWrZisGcRSmTIKp8w5cp2RLgPfH8makRqkXXRT3t3H1yz V07UMHzpsTPAA== Received: from hysteria.proulx.com (hysteria.proulx.com [192.168.230.119]) by joseki.proulx.com (Postfix) with ESMTP id 0C43621151; Fri, 29 May 2020 16:32:51 -0600 (MDT) Received: by hysteria.proulx.com (Postfix, from userid 1000) id 021122DC8E; Fri, 29 May 2020 16:32:50 -0600 (MDT) Date: Fri, 29 May 2020 16:32:50 -0600 From: Bob Proulx To: Yuan Cao Subject: Re: bug#41518: Bug in od? Message-ID: <20200529151544050784197@bob.proulx.com> References: <4d278b06-eb27-e3d2-6e90-fd7d902d5af8@draigBrady.com> <20200528231636675583879@bob.proulx.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 41518 Cc: 41518@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) 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 the file. It feels strange in the environment *today*. But in the 1970's when the 'od' was written it was perfectly natural on the PDP-11 to print out the native machine word in the *native word order* of the PDP-11. During that time most software operated on the native architecture and the idea of being portable to other systems was not yet common. The PDP-11 is a 16-bit word machine. Therefore what you are seeing with the 2-byte integer and the order it is printed is the order that it was printed on the PDP-11 system. And has remained unchanged to the present day. Because it can't change without breaking all historical use. For anyone using od today the best way to use -x is -tx1 which prints bytes in a portable order. Whenever you think to type in -x use -tx1 instead. This avoids breaking historical use and produces the output that you are wanting. > I think it might have been useful to get the "by word" value of the file if > you are working with a binary file historically. One might have stored some > data as a list of shorts. Then, we can easily view the data using "od -x > data_file_name". > > Since memory is so cheap now, people are probably using just using chars > for text, and 4 byte ints or 8 byte ints where they used to use 2 byte ints > (shorts) before. In this case, the "by word" order does not seem to me to > be as useful and violates the principle of least astonishment needlessly. But changing the use of options to a command is a hard problem and cannot be done without breaking a lot of use of it. The better way is not to try. The options to head and tail changed an eon ago and yet just in the last week I ran across a posting where the option change bit someone in the usage change. And since there is no need for any breaking change it is better not to do it. Simply use the correct options for what you want. -tx1 in this case. > It might be interesting to change the option to print values by double word > or quadword instead or add another option to let the users choose to print > by double word or quadword if they want. And the size of 16-bits was a good value for a yester-year. 32-bits has been a good size for some years. Now 64-bits is the most common size. The only way to win is not to play. Better to say the size explicitly. And IMNHO the best size is 1 regardless of architecture. od -Ax -tx1z -v Each of those options have been added over the years and each changes the behavior of the program. Each of those would be a breaking change if they were made the default. Best to ask for what you want explicitly. I strongly recommend https://www.ietf.org/rfc/ien/ien137.txt as required reading. Bob From debbugs-submit-bounces@debbugs.gnu.org Sat May 30 03:36:16 2020 Received: (at 41518) by debbugs.gnu.org; 30 May 2020 07:36:16 +0000 Received: from localhost ([127.0.0.1]:56872 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jew2S-0007eP-5t for submit@debbugs.gnu.org; Sat, 30 May 2020 03:36:16 -0400 Received: from mail-out.m-online.net ([212.18.0.9]:34571) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jew2P-0007eG-HH for 41518@debbugs.gnu.org; Sat, 30 May 2020 03:36:14 -0400 Received: from frontend01.mail.m-online.net (unknown [192.168.8.182]) by mail-out.m-online.net (Postfix) with ESMTP id 49YtXW66MCz1qrg9; Sat, 30 May 2020 09:36:11 +0200 (CEST) Received: from localhost (dynscan1.mnet-online.de [192.168.6.70]) by mail.m-online.net (Postfix) with ESMTP id 49YtXW4SGNz1qtwN; Sat, 30 May 2020 09:36:11 +0200 (CEST) X-Virus-Scanned: amavisd-new at mnet-online.de Received: from mail.mnet-online.de ([192.168.8.182]) by localhost (dynscan1.mail.m-online.net [192.168.6.70]) (amavisd-new, port 10024) with ESMTP id jaJ6QeskeTAL; Sat, 30 May 2020 09:36:11 +0200 (CEST) X-Auth-Info: KsDb3Cx+T0P8oPSjA1nnN4wSvwaSnm+hlahDSOKS1s5ROLWsACTVvHRVGfE1uXRQ Received: from hase.home (ppp-46-244-170-156.dynamic.mnet-online.de [46.244.170.156]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.mnet-online.de (Postfix) with ESMTPSA; Sat, 30 May 2020 09:36:10 +0200 (CEST) Received: by hase.home (Postfix, from userid 1000) id 5FA3C101563; Sat, 30 May 2020 09:36:10 +0200 (CEST) From: Andreas Schwab To: Yuan Cao Subject: Re: bug#41518: Bug in od? References: <4d278b06-eb27-e3d2-6e90-fd7d902d5af8@draigBrady.com> <20200528231636675583879@bob.proulx.com> X-Yow: Why is everything made of Lycra Spandex? Date: Sat, 30 May 2020 09:36:10 +0200 In-Reply-To: (Yuan Cao's message of "Fri, 29 May 2020 16:47:17 -0400") Message-ID: <87lfl96fit.fsf@linux-m68k.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.91 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.4 (/) X-Debbugs-Envelope-To: 41518 Cc: 41518@debbugs.gnu.org, Bob Proulx X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.4 (-) 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 think about UCS-2 characters. Andreas. -- Andreas Schwab, schwab@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different." From unknown Sat Jun 21 03:25:54 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Sat, 27 Jun 2020 11:24:04 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator