se files aren't ever pushed to the bash git repositories (master,
devel).
If Chet doesn't want to patch the primary bash.git to ignore them for
everybody in .gitignore, you can still patch your downstream repo to
ignore them locally by instead adding those exclusions to .git/info/excl
o.
So back to the overall expression: if pipeline2 has non-zero status,
then pipeline3 is run, even though that is the echo statement you
incorrectly surmised would never display.
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3266
Virtualization: qemu.org | libvirt.org
On 04/11/2018 10:57 AM, Chet Ramey wrote:
> Yep, that's an incompatibility. The `c.c' thing in the original report is
> just a red herring, though.
>
> Chet
>
If you are aiming for compatibility with zsh, the fact that `echo **' recurses
is also a bug.
l the pieces that weren't installed the first time).
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3266
Virtualization: qemu.org | libvirt.org
On 05/24/2018 01:29 PM, Eric Blake wrote:
On 05/24/2018 01:18 PM, Chet Ramey wrote:
On 5/24/18 11:40 AM, gabriele balducci wrote:
hi
just tried to build/install readline-8.0-alpha and found the following
glitch:
Thanks for the report. I think a better fix is to not to attempt to
install
ignore-case' as
the two knobs used to fine-tune whether you are doing case-insensitive
completion, and if so, whether -/_ are part of that case-insensitivity.
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3266
Virtualization: qemu.org | libvirt.org
Makes no real difference to me on the Cygwin port. -p1 is slightly
nicer, but it's a scripted solution to apply patches, and very easy to
tweak the script to match whatever the patches look like.
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3266
Virtu
ssing operand
Try 'dirname --help' for more information.
$ dirname -- --
.
So, with that said, do you have an example command line that you are
still confused about, rather than a vague non-report?
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3266
Virtualization: qemu.org | libvirt.org
tml
https://cygwin.com/ml/cygwin/2018-05/msg00334.html
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3266
Virtualization: qemu.org | libvirt.org
other GNU utilities have done it for some
time. What do folks think?
I'm in favor of the idea.
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3266
Virtualization: qemu.org | libvirt.org
locale definition of only the ASCII characters in that range, rather
than the locale's definition of whatever other characters might also be
equivalent (actually, while I know that shopt affects globbing, I don't
know if it also affects regex matching - but if it doesn't, that's
probably a bug that should be fixed).
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3266
Virtualization: qemu.org | libvirt.org
On 09/06/2018 09:17 AM, Chet Ramey wrote:
On 9/5/18 4:39 PM, Eric Blake wrote:
Or, you can use bash's 'shopt -s globasciiranges' which is
supposed to enable Rational Range Interpretation, where even in non-C
locales, a character range bounded by two ASCII characters takes
On 09/06/2018 12:39 PM, Aharon Robbins wrote:
In article ,
Eric Blake wrote:
But bash could be taught to convert any regex that contains a range with
both endpoints ASCII into a different bracket expression before handing
things over to regcomp(). That is, if the user is matching against
[a
On Thu, Nov 24, 2016 at 12:05:20AM -0800, Eric Pruitt wrote:
> In my Bash configuration, I have things setup so Ctrl+Z is no longer
> translated into a signal at the Bash prompt so it can be remapped. Most
> recently, I decided to modify the Bash source to implement this change
r is greater than "$#", this may be
considered a syntax error and a non-interactive shell may exit; if the
shell does not exit in this case, a non-zero exit status shall be
returned. Otherwise, zero shall be returned.
Tested on Fedora 28 with bash-4.4.23-1.fc28.x86_64
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3266
Virtualization: qemu.org | libvirt.org
On 11/8/18 6:03 PM, Chet Ramey wrote:
On 11/8/18 3:37 PM, Eric Blake wrote:
If I'm reading POSIX correctly, shift is a special built-in utility, and if
'$#' is 0 or 1, then 'shift 2' counts as a utility error that shall exit
the shell, per the table in 2.8.1 Consequenc
On 11/9/18 8:52 AM, Chet Ramey wrote:
On 11/9/18 9:47 AM, Eric Blake wrote:
Well, there's STILL a conformance issue - the standard requires that unless
documented otherwise, any time a command line tool exits with non-zero
status, that it outputs a message to stderr explaining the
o is to turn on the shift_verbose option in posix
mode.
Cool - I didn't realize we already had a shopt for that. Yes, it sounds
like in POSIX mode, shift_verbose should be turned on.
On a related note, should turning on POSIX mode also auto-enable xpg_echo?
--
Eric Blake, Principal Softw
ause your /bin/sh is not bash, but probably
dash, and dash has picked a missing file as being treated as always an
error. That does not make it a bug in bash, though, but a difference in
behavior of your /bin/sh.
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3266
Virtualization: qemu.org | libvirt.org
On 11/15/18 12:00 PM, RAL wrote:
Hi,
How is defined the maximum number of characters a variable name can have?
Bash has no hardcoded limit, thus your maximum is dependent on how much
free memory your system has.
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301
t.
If you think the existing convention is confusing, then submit a patch
to change it instead of asking someone else to take on the grunt work.
Otherwise, learn to live with the existing convention (which doesn't
bother me, so I won't be submitting a patch).
--
Eric Blake, P
f distributed version control.
Nothing is preventing you from creating a github clone of the savannah
upstream git repository, and making your patches in whatever way you
prefer using github's processes; the only real leap is realizing that
you submit your patches as emails to this list rather than a
For more details:
http://austingroupbugs.net/view.php?id=221
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3226
Virtualization: qemu.org | libvirt.org
signature.asc
Description: OpenPGP digital signature
ave you do all the work for me".
http://www.catb.org/esr/faqs/smart-questions.html is a great read; it
will teach you how to come across as someone worth chatting to, rather
than an infinite time sink, if you would use the advice in that file to
ask smarter questions.
--
Eric Blake, Principal Software E
ber]]...
So, the %left line that you quoted above IS what defined yacc_EOF to be
a token.
If you've never used yacc/bison before, trying to learn how they work by
using bash as your starting point is a rather heavy crash-course.
--
Eric Blake, Principal Software Engineer
Red Hat, Inc.
On 2/6/19 5:05 PM, Peng Yu wrote:
> On Wed, Feb 6, 2019 at 4:49 PM Eric Blake wrote:
>>
>> On 2/6/19 4:18 PM, Peng Yu wrote:
>>> Hi,
>>>
>>> I deleted the file parser-built, and bash still compiles and an empty
>>> parser-built file will be gen
f unknown
lengths, the cache at least lets us avoid even more malloc()s of the
fixed-size management data structures.
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3226
Virtualization: qemu.org | libvirt.org
signature.asc
Description: OpenPGP digital signature
html#tag_18_10
may be a helpful read for rules on deciding whether a TOKEN is further
resolved into reserved word or a plain WORD (although remember that
bash's parser recognizes more things than are required by the POSIX grammar)
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3226
Virtualization: qemu.org | libvirt.org
signature.asc
Description: OpenPGP digital signature
rates. The above quotes from POSIX demonstrate
ambiguous situations where lexical analysis, rather than parsing alone,
is needed to decide between arithmetic or command substitution; so since
we are already relegated to a lexical decision, complicating the parser
isn't going to buy us any benefit.
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3226
Virtualization: qemu.org | libvirt.org
signature.asc
Description: OpenPGP digital signature
nefits
> of more lenient syntax. What are your thoughts?
Bad idea. Existing scripts can do:
echo = hi
and your proposal would change the semantics of that line from
outputting the string "= hi" to instead assigning to the variable named
$echo.
--
Eric Blake, Principal Software Engine
ght be interrupting the window between open() and fcntl().
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3226
Virtualization: qemu.org | libvirt.org
e are confused
by the locale-specific nature of ranges otherwise).
>
> Repeat-By:
> foo=ABC ; echo ${foo%[A-Z]} ${foo%[:upper:]}
If you want [[:upper:]] to work, you have to spell it correctly.
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3226
Virtualizati
handlers for SEGV operating sanely when there is not
stack overflow. So in the meantime, the core dump is the best you'll get.
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3226
Virtualization: qemu.org | libvirt.org
signature.asc
Description: OpenPGP digital signature
on allows
an easy distinction between normal exit with 8-bit status and exit due
to signal.
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3226
Virtualization: qemu.org | libvirt.org
signature.asc
Description: OpenPGP digital signature
Bash happens to have extension options, so your command
line is not portable, and it is not a bug in bash.
> Please, let's try to avoid losing control of printf like what
> happened to echo, stick to the requirements of POSIX where they
> apply and actually sp
#x27; to output exactly '-x', by virtue
of the fact that it mandates all utilities (other than special builtins)
with the specification 'OPTIONS None.' to parse and ignore '--' as the
end of options, whether or not the utility takes options as an
extension. If NetBSD broke t
Just because Linux does not split whitespace on #! lines does not mean
that all operating systems behave the same. Mention the recent
coreutils 8.30 'env -S' addition for working around interpreter
argument limitations, as well as the use of env to locate bash even
when it is not in /bin.
---
do
from the unquoted backslash.
Yes - sure. But then I'm wondering why the unquoted backtick doesn't
start command substitution:
It may be version dependent:
$ echo ${BASH_VERSINFO[@]}
5 0 7 1 release x86_64-redhat-linux-gnu
$ echo b{Z..a}d
bash: bad substitution: no closing "`"
efore any of the POSIX word expansions, and is logically a separate step.
Then that argues that {Z..a} should produce \\ and \', rather than bare
characters, so that the subsequent quote removal gets back to the
intended character.
--
Eric Blake, Principal Software Engineer
Red Hat, Inc.
sions like that,
when it is already more efficient to use other means of iteration that
do not require bash to keep the entire sequence in memory.
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3226
Virtualization: qemu.org | libvirt.org
On 3/13/20 2:22 PM, Zack Weinberg wrote:
On Fri, Mar 13, 2020 at 3:13 PM Eric Blake wrote:
Unpatched bash 5.0 has a bug where calling $as_echo that contains \ can
result in unintended globbing, where the behavior of the expansion is
dependent on the contents of the current directory. Nasty
...
~$ bash -c 'echo ~nosuchuser'
~nosuchuser
glibc:
bash-5.0$ ldd --version
ldd (Debian GLIBC 2.28-10) 2.28
...
bash-5.0$ ./bash --version
GNU bash, version 5.0.17(2)-release (x86_64-pc-linux-gnu)
...
bash-5.0$ ./bash -c 'echo ~nosuchuser'
~nosuchuser
Eric
On 8/16/20 11:47 AM, Todd A. Jacobs wrote:
Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: darwin19.5.0
Compiler: clang
Compilation CFLAGS: -DSSH_SOURCE_BASHRC -Wno-parentheses -Wno-format-security
uname output: Darwin titan.local 19.6.0 Darwin Kernel Versi
ined.
echo -- "-n foo" # -- -n foo
Also well-defined.
I see nothing in your report about bash disobeying POSIX, but rather
confusion on your part about what POSIX actually requires.
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3226
Virtualization: qemu.org | libvirt.org
ally set it; whereas using
printf is reliably portable.
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3226
Virtualization: qemu.org | libvirt.org
ed-environment-variables-code-injection-attack/
is also a good read, as well as the archives of this list.
--
Eric Blake eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
ith patch 25 still vulnerable to
> CVE-2014-6271?
No. Patch 25 is what solves CVE-2014-6271 (but you will still need to
wait for Patch 26 before having a solution to the weaker CVE-2014-7169).
--
Eric Blake eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
On 09/25/2014 05:58 PM, Chet Ramey wrote:
> On 9/24/14, 5:38 PM, Eric Blake wrote:
>
>> and I'd feel much more comfortable with exporting f()=... as the
>> backdoor for passing the function definition, _particularly_ since the
>> shell already allows functions and v
about it - it's a museum
system, and we should be worried more about modern systems at this point
in time.
--
Eric Blake eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
s
by default, but have bash invoked as /bin/sh refuse to do imports by
default. If the ability to import functions becomes conditional on
argv[0], then I also suggest that bash have a 'set -o' option or 'shopt'
setting that can let the user override the default (a way to invoke
On 09/26/2014 08:45 AM, Nick Bowler wrote:
> On 2014-09-25 15:08 -0700, Linda Walsh wrote:
>> Eric Blake wrote:
>>> Where I'm coming from is that in portable shell programming, you _can't_
>>> assign a value to f()=... The fact that portable programs are now
environment can be reinstated as functions. I'm fairly
certain that Chet will be reasonable about this, and after the worst
fires are put out, we can revisit this.
--
Eric Blake eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
t, directly or
> indirectly, use,
Sorry, but this is a publicly archived list. Your employer's legalese
blurb is unenforceable here.
--
Eric Blake eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
t my application).
If you have questions about RHEL in particular, I suggest asking your
contact at Red Hat rather than trying to get free advice on this list.
(Although my mail address is from redhat.com, I am only an interested
engineer, and NOT an official Red Hat policy maker).
--
Eric Blake eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
wall.com/lists/oss-security/2014/09/25/13
It has the benefit of exporting functions through a namespace that
CANNOT collide with a normal environment variable, and therefore, normal
environment variables CANNOT be used to call into the bash parser
without consent, avoiding all four of CVE-2014-627
On 09/26/2014 02:22 PM, Linda Walsh wrote:
> Eric Blake wrote:
>
>> They are not portable to broken bash. But the argument in these threads
>> is that bash's implementation of function exports should be changed so
>> that _fixed_ bash will once again be POSIX
tch, not Chet's.
>
> -bash-3.2$ bash -c 'x() { echo "functions still work" "$@"; }; export -f x;
> env | egrep "functions still work"'
> BASH_FUNC_x()=() { echo "functions still work" "$@"
Correct, this is symptomatic of a Red Hat build.
--
Eric Blake eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
[posting a rehash of what has been said in several other threads, to
pull all the information into one easier-to-find location]
I know that ShellShock has been getting all the focus lately, but MOST
sites that I have seen that offer advice on how to test whether a build
is vulnerable are testing O
of both approaches - moving shell functions into a
non-colliding namespace (so that arbitrary contents of regular variables
CANNOT trigger parser bugs) and making shell function exports
configurable and off by default.
--
Eric Blake eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
ists.gnu.org/archive/html/bug-bash/2014-09/msg00238.html
--
Eric Blake eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
ully immune to ShellShock:
https://lists.gnu.org/archive/html/bug-bash/2014-09/msg00238.html
--
Eric Blake eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
#x27;s why it
> doesn't do this in posix mode.)
I don't see function export/import as a violation of posix; the only
violation I see is that the implementation is preventing the use of
arbitrary values of normal variables. And the proposed fixes that use
an alternate namespace to avoid collisions have already resolved that issue.
--
Eric Blake eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
On 09/27/2014 02:29 PM, Eric Blake wrote:
> On 09/27/2014 12:53 PM, Chet Ramey wrote:
>
>> $ function /bin/echo () { builtin echo whoops; }
>>
>
>> along with exporting these functions and importing them without complaint.
>>
>> This is obviously bad, and
On 09/27/2014 02:57 PM, Arfrever Frehtes Taifersar Arahesis wrote:
> 2014-09-27 22:29 Eric Blake napisał(a):
>> Thankfully, bash already forbids trying to name a function 'a=b'
>
> It works in bash 4.3.26:
>
> $ function a=b() { echo A; }
> $ "a=b&qu
On 09/27/2014 03:10 PM, Jay Freeman (saurik) wrote:
> [I am terribly sorry that my In-Reply-To is wrong :/]
>
> ----- "Eric Blake" wrote:
>
>> ... Remember, the security hole of
>> Shell Shock is NOT what the function is named, but the fact that
>> arbit
.
If you want a truly minimalist shell that will loudly complain at
attempts to use extensions, use 'posh' instead of 'dash'.
But Chet's point remains - there's no need to dumb down bash to serve as
a minimalist shell, because that's a maintenance burden, and
On 09/27/2014 05:59 PM, Chet Ramey wrote:
> On 9/27/14, 4:29 PM, Eric Blake wrote:
>> On 09/27/2014 12:53 PM, Chet Ramey wrote:
>
>> Right now, we know of no way for an attacker to force an arbitrary
>> variable name - ONLY arbitrary variable contents.
>
> Sure,
On 09/27/2014 07:47 PM, Chet Ramey wrote:
> On 9/27/14, 8:49 PM, Eric Blake wrote:
>> On 09/27/2014 05:59 PM, Chet Ramey wrote:
>>> On 9/27/14, 4:29 PM, Eric Blake wrote:
>>>> On 09/27/2014 12:53 PM, Chet Ramey wrote:
>
>>> We have an opportunity to c
re are still more
patches needed to plug all of the parser holes that Shell Shock has
uncovered.
--
Eric Blake eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
arent
> if used inside bash (eg. echo $FUNC), as opposed of usage by its
> children (wouldn't be hard to change, though).
I consider it an important design goal to ensure that ALL exported
variables cannot be corrupted no matter what their contents are. We
aren't quite there yet
[adding Austin Group]
On 09/28/2014 07:11 PM, Chet Ramey wrote:
> On 9/27/14, 10:03 PM, Eric Blake wrote:
>
>>> Yes, it's an application requirement. Regardless, all the versions of bash
>>> we're talking about here reject non-identifiers.
>>
>> I&
e the environment
and strip out any invalid names before populating the set of shell
variables advertised through 'set' (you can still leave such name/value
pairs in the environment handed to children, unmolested, the way bash
does; it's just that you should not be able to get at or
On 09/30/2014 08:42 AM, Eric Blake wrote:
> Thanks; here's another ksh bug:
>
> $ env 'a|b=' bash -c 'set | grep a"."b'
> $ env 'a|b=' ksh -c 'set | grep a"."b'
> a|b=''
>
> But per the documentation
e upstream source is different, so that doesn't
> match.
Known issue:
https://lists.gnu.org/archive/html/bug-bash/2014-10/msg8.html
has advice on how to proceed if you are too impatient to wait for the
pending respin of the patch.
--
Eric Blake eblake redhat com+1-919-301-3266
Li
On 10/02/2014 07:33 AM, John Wolfe wrote:
> I am curious; why does Bash 4-3 patch 28 contain patches for y.tab.c.
> Is this really what was intended.
Yes, it is intended.
https://lists.gnu.org/archive/html/bug-bash/2014-09/msg00315.html
--
Eric Blake eblake redhat com+1-919-30
On 10/03/2014 03:37 PM, Paul FM wrote:
>
> Bash Version: 4.2
> Patch Level: 47
You are several patches behind.
> Repeat-By:
> while running bash:
> export Y=\(\)\ \{\ ignored\;\ \}\;\ /usr/bin/id
This syntax no longer causes function parsing, as of 4.2 patch level 5
t didn't
compile today was the use of a Unicode codepoint that gets turned into
an alphanumeric in a newer version of the standard. I see no reason to
have that complexity in bash.
This may also be the sort of question worth asking the Austin Group
about, to see if POSIX should be tightened on th
e if getenv has to be redefined?
It already exists, just with a different spelling:
./configure bash_cv_getenv_redef=no
--
Eric Blake eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
On 10/08/2014 11:53 AM, Ángel González wrote:
> Eric Blake wrote:
>> On 10/08/2014 08:52 AM, Stephane Chazelas wrote:
>>> When bash parses code it honours the "blank" character class in
>>> the current locale as token separator.
>>>
>>> F
vulnerability,
only whether a parser bug is present.
--
Eric Blake eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
x27;0+x[`id >/dev/tty`]T'
demonstrates that fsadm is vulnerable for trying to do $(($1)) without
sanitizing $1 first.
--
Eric Blake eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
oid the Shellshock
vulnerability (the problem there was that the namespace that triggered
special handling was infinite, and therefore caused collisions with
regular variables and difficulty in blacklisting when sanitizing across
a security boundary).
--
Eric Blake eblake redhat com+
msg00140.html
Remember, a parser bug is not necessarily an exploitable vulnerability.
It is sufficient to know that bash cannot be exploited once you apply
patch 10 (all 6 CVEs were neutralized by that one patch, as well as any
other as-yet-unreported parser bugs).
--
Eric Blake eblake red
-7187 can be
exploited to remotely attack your system:
f='() { echo vulnerable; } bash -c f
If it prints:
bash: f: command not found
then your system is not vulnerable, no matter how many other parser bugs
it has (6 parser bugs have been assigned a CVE so far, but there are
probably others
ether
it is bash or something else generating the environment garbage).
http://anonscm.debian.org/cgit/collab-maint/at.git/commit/?id=482f5962d
--
Eric Blake eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
a full tarball release of any other official patch;
so I'm not holding my breath that Chet's release process is going to
change. However, making it more obvious on the main webpage that EVERY
tarball needs to be augmented by the current set of official patches
would be a worthwhile improvem
commits ;-)
> can I assume that this includes named pipes?
Named pipes (aka fifos) are notorious for being buggy on Cygwin and
non-available on mingw.
--
Eric Blake eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
rints "bash: f:
command not found", you are secure.
--
Eric Blake eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
it use of --debugger be fatal if a debugger
start file is configured but not present?
- --
Eric Blake eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Public key at http://people.redhat.com/eb
he parser bug to
comply with POSIX.
For comparison, try:
$ echo . ${VAR:=""} .
. .
$ echo . "${VAR:=""}" .
. .
in modern bash, you can see the difference when the parser is behaving
correctly.
> Would it be possible to fix this issue?
Yes, since the issue is in
#x27;s printf could cause a core dump when using %A on
certain long double bit values, until earlier this year).
--
Eric Blake eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org
if it failed to set at least one variable.
Since b was successfully set, 'local' sets $? to 0, which overrides any
status in the embedded $().
You meant to write:
local b
b=$(error); err=$?
--
Eric Blake eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
not how bash
works. 'local' creates something local to the function scope.
Declaring something local through multiple iterations does not change
the scope; the third loop iteration is not changing the value of the
variable, and since the variable is still in scope from the first
iteratio
ing Setjmp instead of setjmp throughout any file that includes
"posixjmp.h". I'll leave it up to you to decide on the best solution
for your coding style. [Meanwhile, I'll file a bug with the Cygwin
folks to see if we can use some namespace tricks in to avoid
problems for c
On 01/23/2015 02:58 PM, Eric Blake wrote:
> http://pubs.opengroup.org/onlinepubs/9699919799/functions/setjmp.html is
> clear:
>
> "It is unspecified whether setjmp() is a macro or a function. If a macro
> definition is suppressed in order to access an actual function, or a
On 01/23/2015 03:53 PM, Eric Blake wrote:
> On 01/23/2015 02:58 PM, Eric Blake wrote:
>> http://pubs.opengroup.org/onlinepubs/9699919799/functions/setjmp.html is
>> clear:
>>
>> "It is unspecified whether setjmp() is a macro or a function. If a macro
>> defin
tatic void
bind_arrow_keys_internal (map)
--
Eric Blake eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
har (c)))
+#define ISPRINT(c) (IN_CTYPE_DOMAIN (c) && isprint (to_uchar (c)))
+#define ISUPPER(c) (IN_CTYPE_DOMAIN (c) && isupper (to_uchar (c)))
+#define ISXDIGIT(c)(IN_CTYPE_DOMAIN (c) && isxdigit (to_uchar (c)))
#define _rl_lowercase_p(c) (NON_NEGATIVE(c) && ISLOWER(c))
#define _rl_uppercase_p(c) (NON_NEGATIVE(c) && ISUPPER(c))
--
Eric Blake eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
and it would be easier to follow the history to see what really changed
without being inundated by all the noise on the side file
creation-deletion loops.
--
Eric Blake eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
On 01/23/2015 04:31 PM, Eric Blake wrote:
> Thus, the following is the minimal patch for Cygwin to have correct
> compilation (both setjmp and setjmp_nosigs usage points in bash will
> have identical behavior). Although I still think that you ought to fix
> more than just Cygwin by
501 - 600 of 698 matches
Mail list logo
