Re: [ANNOUNCEMENT] Updated: bash-4.3.39-2
On 09/28/2015 08:56 AM, Eric Blake wrote: > On 09/28/2015 08:30 AM, Mikhail Usenko wrote: > >> But catching that bug (in upstream?) hasn't changed anything >> at least on my installation: > > Okay, I can see the disappearing \r even on a binary mount, so it > appears to be unrelated to the fix for text mounts. > > Meanwhile, doing something like this (with a shorter sender): > > # sender | od -An -tx1 > \r\n\r\r\n\r\r\r\n 0d 0a 0d 0d 0a 0d 0d 0d 0a > > shows that the pipeline is not eating the \r, but rather it appears to > be an issue in 'read'. I'm still investigating, but thanks for the > recipe, as it gives me something to focus on. I think I've figured out the problem in the 'read' builtin, and the new bash-4.3.43-5 should fix it. Please test to make sure. https://lists.gnu.org/archive/html/bug-bash/2016-08/msg00010.html -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: [ANNOUNCEMENT] Updated: bash-4.3.39-2
On Mon, 28 Sep 2015 08:56:14 -0600
Eric Blake <...> wrote:
>
> 'echo -n' and 'echo -e' are non-portable (even in bash; because I can
> use 'shopt -s xpgecho' to get POSIX-mandated behavior). Use 'printf'
> instead.
>
xpg_echo doesn't change 'echo -ne' behavior
('echo -e' force backslash-escape sequences expansion independently)
$ shopt xpg_echo
xpg_echooff
$ echo -e '\r\n' | od -tx1
000 0d 0a 0a
003
$ shopt -s xpg_echo
$ shopt xpg_echo
xpg_echoon
$ echo -e '\r\n' | od -tx1
000 0d 0a 0a
003
$ echo '\r\n' | od -tx1
000 0d 0a 0a
003
--
Mike
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [ANNOUNCEMENT] Updated: bash-4.3.39-2
On 09/28/2015 10:48 AM, Mikhail Usenko wrote: > On Mon, 28 Sep 2015 08:56:14 -0600 > Eric Blake <...> wrote: >> >> 'echo -n' and 'echo -e' are non-portable (even in bash; because I can >> use 'shopt -s xpgecho' to get POSIX-mandated behavior). Use 'printf' >> instead. >> > > xpg_echo doesn't change 'echo -ne' behavior xpg_echo in isolation does not, and POSIXLY_CORRECT in isolation does not, but together they DO affect echo: $ bash -c 'echo -n hi' hi $ bash -c 'shopt -s xpg_echo; echo -n hi' hi $ bash -c 'POSIXLY_CORRECT=1; echo -n hi' hi $ bash -c 'POSIXLY_CORRECT=1; shopt -s xpg_echo; echo -n hi' -n hi -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: [ANNOUNCEMENT] Updated: bash-4.3.39-2
On Thu, 24 Sep 2015 15:10:25 -0600
Eric Blake <...> wrote:
> On 06/04/2015 03:51 AM, Mikhail Usenko wrote:
> > Eric Blake (cygwin) <...> wrote:
> >> 4.3.39-2
> >
> > Hello, Eric.
> > It has the same issue as in the previous version:
> > eating one \r from the odd numbered chains of the \r.
> >
>
> Please try the (currently-experimental) 4.3.42-4, which should fix the
> issues observed.
>
On Thu, 24 Sep 2015 10:55:45 -0600
Eric Blake <...> wrote:
>
> Jeff Downs helped me investigate off-list, and I think he found the
> culprit (a typo in input.c that requested O_TEXT when it meant B_TEXT,
> when mapping from open() flags to bash's internal B_* flags). I'm
> building a new bash build right now, and will shortly be posting it for
> testing.
>
Hello, Eric.
Thank you for working on this annoying problem that stops
some parsing scripts (that worked in cygwin in 3-4 bash versions ago)
to work correctly and thereby so the cygwin/bash overall employing.
But catching that bug (in upstream?) hasn't changed anything
at least on my installation:
---%<--%<---
#! /bin/bash
bash -version | head -n1
echo
sender()
{
echo -n '\r\n' >&2
echo -ne '\r\n'
sleep 1
echo -n '\r\r\n' >&2
echo -ne '\r\r\n'
sleep 1
echo -n '\r\r\r\n' >&2
echo -ne '\r\r\r\n'
sleep 1
echo -n '\r\r\r\r\n' >&2
echo -ne '\r\r\r\r\n'
sleep 1
echo -n '\r\r\r\r\r\n' >&2
echo -ne '\r\r\r\r\r\n'
sleep 1
}
receiver()
{
t=""
while read t || [ "$t" ]; do
echo -ne ": \t"
od -A n -t x1 <<<"$t"
done >&2
}
# implicit pipe
receiver < <(sender)
# explicit pipeline
sender | receiver
--->%-->%---
$ ./cygwin-test.sh
GNU bash, version 4.3.42(4)-release (x86_64-unknown-cygwin)
\r\n:0a
\r\r\n: 0d 0d 0a
\r\r\r\n:0d 0d 0a
\r\r\r\r\n: 0d 0d 0d 0d 0a
\r\r\r\r\r\n:0d 0d 0d 0d 0a
\r\n:0a
\r\r\n: 0d 0d 0a
\r\r\r\n:0d 0d 0a
\r\r\r\r\n: 0d 0d 0d 0d 0a
\r\r\r\r\r\n:0d 0d 0d 0d 0a
--
Mike
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [ANNOUNCEMENT] Updated: bash-4.3.39-2
On 09/28/2015 08:30 AM, Mikhail Usenko wrote:
> But catching that bug (in upstream?) hasn't changed anything
> at least on my installation:
Okay, so it sounds like your issue is separate.
>
> ---%<--%<---
> #! /bin/bash
> bash -version | head -n1
> echo
>
> sender()
> {
> echo -n '\r\n' >&2
> echo -ne '\r\n'
'echo -n' and 'echo -e' are non-portable (even in bash; because I can
use 'shopt -s xpgecho' to get POSIX-mandated behavior). Use 'printf'
instead.
> receiver()
> {
> t=""
> while read t || [ "$t" ]; do
> echo -ne ": \t"
> od -A n -t x1 <<<"$t"
> done >&2
> }
>
>
> # implicit pipe
> receiver < <(sender)
>
> # explicit pipeline
> sender | receiver
Okay, I can see the disappearing \r even on a binary mount, so it
appears to be unrelated to the fix for text mounts.
Meanwhile, doing something like this (with a shorter sender):
# sender | od -An -tx1
\r\n\r\r\n\r\r\r\n 0d 0a 0d 0d 0a 0d 0d 0d 0a
shows that the pipeline is not eating the \r, but rather it appears to
be an issue in 'read'. I'm still investigating, but thanks for the
recipe, as it gives me something to focus on.
--
Eric Blake eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
Re: [ANNOUNCEMENT] Updated: bash-4.3.39-2
On 09/28/2015 09:04 AM, Tim Higgins wrote: > Team > When I run startx I get the following error. > higginst@HigginsT-LT-W7 ~ > $ startx > And this is related to bash, how? Please don't top-post or commandeer unrelated threads. If you have an unrelated question, start a new thread. > > > CONFIDENTIALITY: This e-mail (including any attachments) may contain > confidential, And also please don't send unenforceable legalese to this publicly-archived list. If your employer mandates this junk, then send from a different account (gmane is one way to post to this list via the web rather than an employer-botched email). -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: [ANNOUNCEMENT] Updated: bash-4.3.39-2
On 06/04/2015 03:51 AM, Mikhail Usenko wrote: > Eric Blake (cygwin) <...> wrote: >> 4.3.39-2 > > Hello, Eric. > It has the same issue as in the previous version: > eating one \r from the odd numbered chains of the \r. > Please try the (currently-experimental) 4.3.42-4, which should fix the issues observed. -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: [ANNOUNCEMENT] Updated: bash-4.3.39-2
Eric Blake (cygwin) ... wrote:
4.3.39-2
Hello, Eric.
It has the same issue as in the previous version:
eating one \r from the odd numbered chains of the \r.
bash-4.3.39-2
-
$ echo -ne \r\n | { read t; echo $t; } | od -tx1
000 0a
001
$ echo -ne \r\r\n | { read t; echo $t; } | od -tx1
000 0d 0d 0a
003
$ echo -ne \r\r\r\n | { read t; echo $t; } | od -tx1
000 0d 0d 0a
003
$ echo -ne \r\r\r\r\n | { read t; echo $t; } | od -tx1
000 0d 0d 0d 0d 0a
005
$ echo -ne \r\r\r\r\r\n | { read t; echo $t; } | od -tx1
000 0d 0d 0d 0d 0a
005
$ echo -ne \r\r\r\r | { read t; echo $t; } | od -tx1
000 0d 0d 0d 0d 0a
005
$ echo -ne \r\r\r\r\r | { read t; echo $t; } | od -tx1
000 0d 0d 0d 0d 0a
005
bash-4.3.33-1
-
$ echo -ne \r\n | { read t; echo $t; } | od -tx1
000 0a
001
$ echo -ne \r\r\n | { read t; echo $t; } | od -tx1
000 0d 0d 0a
003
$ echo -ne \r\r\r\n | { read t; echo $t; } | od -tx1
000 0d 0d 0a
003
$ echo -ne \r\r\r\r\n | { read t; echo $t; } | od -tx1
000 0d 0d 0d 0d 0a
005
$ echo -ne \r\r\r\r\r\n | { read t; echo $t; } | od -tx1
000 0d 0d 0d 0d 0a
005
$ echo -ne \r\r\r\r | { read t; echo $t; } | od -tx1
000 0d 0d 0d 0d 0a
005
$ echo -ne \r\r\r\r\r | { read t; echo $t; } | od -tx1
000 0d 0d 0d 0d 0a
005
--
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [ANNOUNCEMENT] Updated: bash-4.3.39-2
On 06/04/2015 03:51 AM, Mikhail Usenko wrote:
Eric Blake (cygwin) ... wrote:
4.3.39-2
Hello, Eric.
It has the same issue as in the previous version:
eating one \r from the odd numbered chains of the \r.
Yes, I know there are still \r issues, although I appreciate the test
case as I'm not sure I have seen this particular complaint.
$ echo -ne \r\n | { read t; echo $t; } | od -tx1
'echo -ne' is non-portable (I can break it with 'shopt -s xpg_echo');
get used to using 'printf' instead.
--
Eric Blake eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
[ANNOUNCEMENT] Updated: bash-4.3.39-2
A new release of bash, 4.3.39-2, has been uploaded and will soon reach a
mirror near you; leaving 4.3.33-1 as the previous version.
NEWS:
=
This is my second build of bash 4.3 for cygwin, incorporating several
new upstream official patches and working around a change in make 4.1
VPATH behavior.
I am aware of an issue reported with using bash on text mode mounts, but
have not yet had time to investigate if the fault lies in bash or in
cygwin1.dll; this build was done solely as a refresh to a newer
patchlevel while I still investigate.
This build of bash is immune to the ShellShock vulnerabilities (although
unpatched bash 4.3 is vulnerable, the official upstream patches solve
the issue). By now, you should no longer be running a vulnerable bash,
but to double check you can run the following test to make sure you are
not subject to arbitrary remote code execution due to ShellShock:
$ env 'bad=() { echo vulnerable; }' bash -c bad
If it prints bash: bad: command not found, your version of bash is
safe and not subject to remote exploits. If it prints vulnerable, you
need to upgrade now.
There are a few things you should be aware of before using this version:
1. When using binary mounts, cygwin programs try to emulate Linux. Bash
on Linux does not understand \r\n line endings, but interprets the \r
literally, which leads to syntax errors or odd variable assignments.
Therefore, you will get the same behavior on Cygwin binary mounts by
default.
2. d2u is your friend. You can use it to convert any problematic script
into binary line endings.
3. Cygwin text mounts automatically work with either line ending style,
because the \r is stripped before bash reads the file. If you
absolutely must use files with \r\n line endings, consider mounting the
directory where those files live as a text mount. However, text mounts
are not as well tested or supported on the cygwin mailing list, so you
may encounter other problems with other cygwin tools in those directories.
4. This version of bash has a cygwin-specific set option, named igncr,
to force bash to ignore \r, independently of cygwin's mount style. As
of bash-3.2.3-5, it controls regular scripts, command substitution, and
sourced files. I hope to convince the upstream bash maintainer to
accept this patch into a future bash release even on Linux, rather than
keeping it a cygwin-specific patch, but only time will tell. There are
several ways to activate this option:
4a. For a single affected script, add this line just after the she-bang:
(set -o igncr) 2/dev/null set -o igncr; # comment is needed
4b. For a single script, invoke bash explicitly with the option, as in
'bash -o igncr ./myscript' rather than the simpler './myscript'.
4c. To affect all scripts, export the environment variable BASH_ENV,
pointing to a file that sets the shell option as desired. Bash will
source this file on startup for every script.
4d. Added in the bash-3.2-2 release: export the environment variable
SHELLOPTS with igncr included in it. It is read-only from within bash,
but you can set it before invoking bash; once in bash, it auto-tracks
the current state of 'set -o igncr'. If exported, then all bash child
processes inherit the same option settings; with the exception added in
3.2.9-11 that certain interactive options are not inherited in
non-interactive use.
4e. bash-4.1.9-1 dropped support for 'shopt -s igncr'; it did not make
sense to support the option through both set and shopt, and SHELLOPTS
proved to be more powerful.
5. You can also experiment with the IFS variable for controlling how
bash will treat \r during variable expansion.
6. There are varying levels of speed at which bash operates. The
fastest is on a binary mount with igncr disabled (the default behavior).
Next would be text mounts with igncr disabled and no \r in the
underlying file. Next would be binary mounts with igncr enabled. And
the slowest that bash will operate is on text mounts with igncr enabled.
7. As additional cygwin extensions, this version of bash includes:
7a. EXECIGNORE - a colon-separated list of glob patterns to ignore
when completing on executables. EXECIGNORE=*.dll is common.
7b. completion_strip_exe - using 'shopt -s completion_strip_exe'
makes completion strip .exe suffixes
8. This version of bash is immune to ShellShock (CVE-2014-6271 and
friends) because it exports functions via 'BASH_FUNC_foo%%=' rather than
'foo=' environment variables. However, doing this has exposed
weaknesses in some other utilities like 'ksh' or 'at' that fail to scrub
their environment to exclude what is not a valid name for them.
9. If you don't like how bash behaves, then propose a patch, rather than
proposing idle ideas. This turn of events has already been talked to
death on the mailing lists by people with many ideas, but few patches.
Thanks to Dan Colascione for providing the EXECIGNORE and
completion_strip_exe patches.
Remember, you must not have any bash or /bin/sh instances running when
you
