GNU bug report logs -
#26372
Base64 inserts carriage return
Previous Next
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 26372 in the body.
You can then email your comments to 26372 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-coreutils <at> gnu.org
:
bug#26372
; Package
coreutils
.
(Wed, 05 Apr 2017 15:27:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Goulven Guillard <lecotegougdelaforce <at> free.fr>
:
New bug report received and forwarded. Copy sent to
bug-coreutils <at> gnu.org
.
(Wed, 05 Apr 2017 15:27:03 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
Hi,
It seems `base64` inserts a carriage return ("Cg==") when encoding a
string :
$ echo foobar|base64
Zm9vYmFyCg==
If this is the desired behaviour, it should at least be documented since
it is not obvious (and BTW different from e.g. PHP base64_encode).
Confirmed with coreutils 8.23-4 under Debian and coreutils 2.24-8.fc23
under Fedora.
Regards,
Goulven Guillard.
Information forwarded
to
bug-coreutils <at> gnu.org
:
bug#26372
; Package
coreutils
.
(Wed, 05 Apr 2017 15:43:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 26372 <at> debbugs.gnu.org (full text, mbox):
tag 26372 notabug
close 26372
stop
Hello,
On 04/05/2017 06:39 AM, Goulven Guillard wrote:
> It seems `base64` inserts a carriage return ("Cg==") when encoding a
> string :
>
> $ echo foobar|base64
> Zm9vYmFyCg==
Not exactly - it is "echo" which adds the newline and base64 simply
encodes all its input.
Observe the following:
$ echo foobar | od -c
0000000 f o o b a r \n
0000007
"printf" can be used for finer control over
your printed strings - it will not add newline
unless you request it:
$ printf foobar | base64
Zm9vYmFy
$ printf 'foobar\n' | base64
Zm9vYmFyCg==
As such I'm closing this bug report, but discussion can continue
by replying to this thread.
regards,
- assaf
Added tag(s) notabug.
Request was from
Assaf Gordon <assafgordon <at> gmail.com>
to
control <at> debbugs.gnu.org
.
(Wed, 05 Apr 2017 15:43:02 GMT)
Full text and
rfc822 format available.
bug closed, send any further explanations to
26372 <at> debbugs.gnu.org and Goulven Guillard <lecotegougdelaforce <at> free.fr>
Request was from
Assaf Gordon <assafgordon <at> gmail.com>
to
control <at> debbugs.gnu.org
.
(Wed, 05 Apr 2017 15:43:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-coreutils <at> gnu.org
:
bug#26372
; Package
coreutils
.
(Wed, 05 Apr 2017 15:45:03 GMT)
Full text and
rfc822 format available.
Message #15 received at submit <at> debbugs.gnu.org (full text, mbox):
Le 05/04/2017 à 12:39, Goulven Guillard a écrit :
> It seems `base64` inserts a carriage return ("Cg==") when encoding a
> string :
>
> $ echo foobar|base64
> Zm9vYmFyCg==
I just figured it was not a carriage return ("\r") but a simple newline
("\n"). I was misleaded because for some reason my PHP form translates
"\n" into "\r\n" during the POST submission.
Anyway, it doesn't change much the issue.
Regards,
Goulven Guillard.
Information forwarded
to
bug-coreutils <at> gnu.org
:
bug#26372
; Package
coreutils
.
(Wed, 05 Apr 2017 15:56:02 GMT)
Full text and
rfc822 format available.
Message #18 received at 26372 <at> debbugs.gnu.org (full text, mbox):
Hello,
On 04/05/2017 07:35 AM, Goulven Guillard wrote:
> I just figured it was not a carriage return ("\r") but a simple newline
> ("\n"). I was misleaded because for some reason my PHP form translates
> "\n" into "\r\n" during the POST submission.
While PHP and HTTP are outside the scope of GNU coreutils,
it's worth noting that the HTTP standard (which include POST
submissions) mandates "\r\n" (CR,LF) as line-endings in forms and in
headers, e.g.:
in HTTP headers:
https://www.w3.org/Protocols/rfc2616/rfc2616-sec4.html
In FORMS:
"Line breaks, as in multi-line text field values,
are represented as CR LF pairs, i.e. `%0D%0A'."
from: https://www.w3.org/MarkUp/html-spec/html-spec_8.html#SEC8.2.1
> Anyway, it doesn't change much the issue.
It doesn't, and the issue is still in "echo", not in "base64" :)
regards,
- assaf
Information forwarded
to
bug-coreutils <at> gnu.org
:
bug#26372
; Package
coreutils
.
(Thu, 06 Apr 2017 08:40:01 GMT)
Full text and
rfc822 format available.
Message #21 received at 26372 <at> debbugs.gnu.org (full text, mbox):
Le 05/04/2017 à 17:55, Assaf Gordon a écrit :
> It doesn't, and the issue is still in "echo", not in "base64" :)
As well as in vim default configuration, which fortunately I figured
before to complain again (use binary mode and ":set noeol" if you don't
want EOL to be added…).
I guess I'll have to pipe to `tr -d '\n'` to get rid of them.
Many thanks for the explanations (especially about HTTP, this will save
me quite some painful googling…) and demonstration of `od`.
Regards,
Goulven.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Thu, 04 May 2017 11:24:04 GMT)
Full text and
rfc822 format available.
This bug report was last modified 8 years and 106 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.