On 3/24/20 4:22 PM, Bjarni Ingi Gislason wrote:
> Bash Version: 5.0
> Patch Level: 16
> Release Status: release
>
> Description:
> [Detailed description of the problem, suggestion, or complaint.]
>
> The input file is from Debian testing.
>
> Warnings
from Debian testing.
Warnings from "mandoc" and "test-groff".
Repeat-By:
[Describe the sequence of events that causes the problem
to occur.]
mandoc -T lint bash.1
test-groff -b -e -mandoc -T utf8 -rF0 -t -w w -z bash.1
[ "test-groff" is a d
On 12/29/18 5:44 PM, Peng Yu wrote:
>> That code hasn't really changed in almost twenty years. All the testing
>> was done long ago.
>
> Do you keep all the testing code in the bash repository?
Yes. The test suite exists in the tests subdirectory.
> Given the fugal
> That code hasn't really changed in almost twenty years. All the testing
> was done long ago.
Do you keep all the testing code in the bash repository? Or you keep
the testing code separately from the bash source? Given the fugal
testing code that is in the bash source, it is doesn&
On 12/27/18 6:58 PM, Peng Yu wrote:
> Since the main() function is already there, why there is not already
> an easy way to compile it? How do you do unit-testing then for the
> code?
That code hasn't really changed in almost twenty years. All the testing
was done long ago.
(I j
On 12/27/18 6:58 PM, Peng Yu wrote:
>> So you need a definition for xmalloc. The easiest thing to do is to add
>> an xmalloc function in the TEST_HASHING block, or you could follow the
>> directions in the comment there.
>>
>> Sooner or later, you're going to have to pick this stuff up on your own
On Fri, Dec 28, 2018 at 4:28 AM Peng Yu wrote:
> We are talking about unit testing in the bash C source code, not bash
> scripts.
>
While toying with the loadable builtins I came up with this:
https://github.com/pgas/newt_builtin/blob/master/make.libbash
you need to set BASH_PATH s
We are talking about unit testing in the bash C source code, not bash scripts.
On Thu, Dec 27, 2018 at 8:03 PM G. Branden Robinson
wrote:
>
> At 2018-12-27T17:34:49-0800, Eduardo Bustamante wrote:
> > On Thu, Dec 27, 2018 at 5:15 PM Peng Yu wrote:
> > (...)
> > > S
At 2018-12-27T17:34:49-0800, Eduardo Bustamante wrote:
> On Thu, Dec 27, 2018 at 5:15 PM Peng Yu wrote:
> (...)
> > Since the main() function is already there, why there is not already
> > an easy way to compile it? How do you do unit-testing then for the
> > code?
&
On Thu, Dec 27, 2018 at 5:15 PM Peng Yu wrote:
(...)
> Since the main() function is already there, why there is not already
> an easy way to compile it? How do you do unit-testing then for the
> code?
This is very easy to figure out from the source code, right :)?
(Hint: there is
unning_trap", referenced from:
_internal_malloc in libmalloc.a(malloc.o)
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
Since the main() function is already there, why there is not already
an easy way to compile it? How do you do unit-testing then for the
code?
--
Regards,
Peng
On 12/26/18 4:31 PM, Peng Yu wrote:
> Hi,
>
> I'd like to compile hashlib.c to try its main(). But I got the
> following error. What is the correct commands to compile it? Thanks.
Think about the error message:
> "_xmalloc", referenced from:
> _hash_create in hashlib.o
> _hash_copy
Hi,
I'd like to compile hashlib.c to try its main(). But I got the
following error. What is the correct commands to compile it? Thanks.
$ gcc -DPROGRAM='"bash"' -DCONF_HOSTTYPE='"x86_64"'
-DCONF_OSTYPE='"darwin17.7.0"'
-DCONF_MACHTYPE='"x86_64-apple-darwin17.7.0"' -DCONF_VENDOR='"apple"'
-DLOCAL
On 10/01/2017 11:31 AM, L A Walsh wrote:
cmd=$(PATH=/stdpath type -p cmd)
I use this kind of construction with 'type -p' regularly:
! cmd=$(type -p cmd) && echo "ABEND: Executable cmd not in PATH" && exit
Then $cmd can be used to execute the binary, and not some alias or
function. This is th
Pierre Gaston wrote:
Besides the fact that most people don't use alias in script
---
That's due to bash being non-POSIX compatible, by default in regard to
aliases. Aliases are designed to "always be there" and always be "on"
unless
explicitly turned off so people could rely on them.
ould prefer (and have least surprise) if functions
> were always considered to be "executable" (with "-x" returning
> true).
>
> A second case: an alias could be seen (and tested) as similar to
> variable access:
>
> I.e. if an alias pointed to an executable, e
case: an alias could be seen (and tested) as similar to
variable access:
I.e. if an alias pointed to an executable, e.g.
alias Ls=$(type -P ls)
I'd like to see the shell intelligent enough to do an executable
test on :
-x "${BASH_ALIASES[Ls]}"
and thirdly, testing, *either*, wh
On Tue, Jul 28, 2015 at 6:51 AM, Chet Ramey wrote:
> On 7/20/15 6:15 PM, James Chang wrote:
>
> > > I recently ran into an odd issue running the testsuite for bash.
> After
> > > running the scripts, /tmp/xx isn't deleted, and another user can't
> run the
> > > testsuite due to permis
On 7/20/15 6:15 PM, James Chang wrote:
> > I recently ran into an odd issue running the testsuite for bash. After
> > running the scripts, /tmp/xx isn't deleted, and another user can't run
> the
> > testsuite due to permission errors. Is it possible to specify bash not
> to
> > u
On Mon, Jul 20, 2015 at 1:55 PM, Chet Ramey wrote:
> On 7/20/15 11:57 AM, James Chang wrote:
> > Hello bash community,
> >
> > I recently ran into an odd issue running the testsuite for bash. After
> > running the scripts, /tmp/xx isn't deleted, and another user can't run
> the
> > testsuite due
On 7/20/15 11:57 AM, James Chang wrote:
> Hello bash community,
>
> I recently ran into an odd issue running the testsuite for bash. After
> running the scripts, /tmp/xx isn't deleted, and another user can't run the
> testsuite due to permission errors. Is it possible to specify bash not to
> use
Hello bash community,
I recently ran into an odd issue running the testsuite for bash. After
running the scripts, /tmp/xx isn't deleted, and another user can't run the
testsuite due to permission errors. Is it possible to specify bash not to
use /tmp/xx?
Thanks,
James
Hello bash community,
I recently ran into an odd issue running the testsuite for bash. After
running the scripts, /tmp/xx isn't deleted, and another user can't run the
testsuite due to permission errors. Is it possible to specify bash not to
use /tmp/xx?
Thanks,
James
There is a new branch in the bash git repository on savannah: bash-4.4-testing.
This will hold the various pre-release versions of bash-4.4 until that
release is final. The initial set of commits consists of the
bash-4.4-alpha release. A more traditional tarfile-based release will
follow soon
The OP's issue isn't bash-specific.
The behavior of test WRT symbolic links is specified in POSIX, cf.
http://pubs.opengroup.org/onlinepubs/9699919799/utilities/test.html
Specifically:
"With the exception of the -h pathname and -L pathname primaries, if a
pathname argument is a symbolic link, te
2015-02-09 14:59:06 -0700, Bob Proulx:
[...]
> The idea is that symlinks should be completely transparent and
> invisible to most applications. The idea is that when normal things
> are run they don't realize they are using a symlink. Behavior would
> be exactly the same as if it were a regular f
The current behaviour is according to the intended functionality of
symlinks when they first appeared, i e to create first-rank local
references across få boundaries. cf hard links.
Hans J. Albertsson
>From my Nexus 5
Den 10 feb 2015 10:04 skrev "Jonathan Hankins" :
> $ touch foo
> $ ln -s foo ba
$ touch foo
$ ln -s foo bar
$ [[ -f foo ]] && [[ ! -h foo ]] && echo "exists and is not a symlink"
exists and is not a symlink
$ [[ -f bar ]] && [[ ! -h bar ]] && echo "exists and is not a symlink"
$
-Jonathan Hankins
On Mon, Feb 9, 2015 at 6:00 PM, Cheng Rk wrote:
>
>
> On Monday, February 9,
On Monday, February 9, 2015 3:13 PM, Andreas Schwab
wrote:
Cheng Rk writes:
>> Then the builtin test help need a documentation fix, right?
You're addressing different lines but I am saying this line is inaccurate,
right?
-f FILETrue if file exists and is a regular file.
Is there
Cheng Rk writes:
> Then the builtin test help need a documentation fix, right?
test: test [expr]
Evaluate conditional expression.
Exits with a status of 0 (true) or 1 (false) depending on
the evaluation of EXPR. Expressions may be unary or binary. Unary
expressions are oft
On Monday, February 9, 2015 1:59 PM, Andreas Schwab
wrote:
>> According this documentation `help test`, I am expecting it should return
>> false on anything other than a regular file,
>>
>> -f FILETrue if file exists and is a regular file.
>>
>>
>> but why it returned true on a symlink
2015-02-09 22:00 GMT+01:00 Cheng Rk :
> According this documentation `help test`, I am expecting it should return
> false on anything other than a regular file,
>
> -f FILETrue if file exists and is a regular file.
>
>
> but why it returned true on a symlink to a regular file?
>
> $ [ -f t
Cheng Rk writes:
> According this documentation `help test`, I am expecting it should return
> false on anything other than a regular file,
>
> -f FILETrue if file exists and is a regular file.
>
>
> but why it returned true on a symlink to a regular file?
(bash) Bash Conditional Expres
On Mon, Feb 09, 2015 at 09:00:12PM +, Cheng Rk wrote:
> -f FILETrue if file exists and is a regular file.
>
> but why it returned true on a symlink to a regular file?
>
> $ [ -f tmp/sym-link ] && echo true
> true
It's supposed to work this way. -f resolves symlinks and tests the
tar
Cheng Rk wrote:
> According this documentation `help test`, I am expecting it should
> return false on anything other than a regular file,
>
> -f FILETrue if file exists and is a regular file.
>
> but why it returned true on a symlink to a regular file?
>
> $ [ -f tmp/sym-link ] && echo
On 02/09/2015 02:00 PM, Cheng Rk wrote:
>
>
> To bug-bash@gnu.org:
>
>
> According this documentation `help test`, I am expecting it should return
> false on anything other than a regular file,
>
> -f FILETrue if file exists and is a regular file.
>
>
> but why it returned true on a
On Mon, Feb 09, 2015 at 09:00:12PM +, Cheng Rk wrote:
>
> To bug-bash@gnu.org:
>
> According this documentation `help test`, I am expecting it should
> return false on anything other than a regular file,
>
> -f FILETrue if file exists and is a regular file.
>
> but why it returned t
from bash(1):
Unless otherwise specified, primaries that operate on files follow
symbolic links and operate on the target of the link, rather than the
link itself.
On Mon, Feb 9, 2015 at 1:00 PM, Cheng Rk wrote:
>
>
> To bug-bash@gnu.org:
>
>
> According this documentation `help test`, I am expe
On 2/9/15 4:00 PM, Cheng Rk wrote:
>
>
> To bug-bash@gnu.org:
>
>
> According this documentation `help test`, I am expecting it should return
> false on anything other than a regular file,
>
> -f FILETrue if file exists and is a regular file.
>
>
> but why it returned true on a syml
To bug-bash@gnu.org:
According this documentation `help test`, I am expecting it should return false
on anything other than a regular file,
-f FILETrue if file exists and is a regular file.
but why it returned true on a symlink to a regular file?
$ [ -f tmp/sym-link ] && echo true
eds to be covered by tests to detect the problem
> (that we would need 4-way or 5-way testing).
Uh, what? This seems like a school/research project for a course that
I obviously don't know, but would you mind explainin what n-way
combinations are and why should we care?
> This may depen
omplex and that a high proportion of
the possible input space needs to be covered by tests to detect the problem
(that we would need 4-way or 5-way testing).
This may depend on how tailored the fuzz tests are for finding this
particular bug. Obviously they could be very narrowly tailored and not
On 10/10/14, 10:55 AM, Stephane Chazelas wrote:
> 2014-10-10 10:17:40 -0400, Chet Ramey:
> [...]
>>> bash -c '(( XDG_VTNR < 7 ))
>>>
>>> That allows arbitrary code execution (and can't easily be
>>> fixed without breaking backward compatibility).
>>>
>>> Try with "export XDG_VTNR='a[$(echo>&2 vulne
2014-10-10 09:04:10 -0600, Eric Blake:
> On 10/10/2014 08:55 AM, Stephane Chazelas wrote:
>
> > But I can't see why the content of a variable should be
> > interpreted as anything else than an arithmetic expression just
> > because it's in an array subscript.
>
> For the record, there are vulnera
On 10/10/2014 08:55 AM, Stephane Chazelas wrote:
> But I can't see why the content of a variable should be
> interpreted as anything else than an arithmetic expression just
> because it's in an array subscript.
For the record, there are vulnerable shell scripts in the wild that fail
to sanitize t
2014-10-10 10:17:40 -0400, Chet Ramey:
[...]
> > bash -c '(( XDG_VTNR < 7 ))
> >
> > That allows arbitrary code execution (and can't easily be
> > fixed without breaking backward compatibility).
> >
> > Try with "export XDG_VTNR='a[$(echo>&2 vulnerable)]'".
>
> Sure, and that's documented, inten
On 10/10/14, 5:40 AM, Stephane Chazelas wrote:
> 2014-10-09 21:35:09 -0400, Chet Ramey:
>> On 10/9/14, 6:06 PM, Pádraig Brady wrote:
>>> On 10/09/2014 08:46 PM, Rick Karcich (rkarcich) wrote:
>>>> Hello Chet,
>>>>
>>>> Re: testing for S
2014-10-09 21:35:09 -0400, Chet Ramey:
> On 10/9/14, 6:06 PM, Pádraig Brady wrote:
> > On 10/09/2014 08:46 PM, Rick Karcich (rkarcich) wrote:
> >> Hello Chet,
> >>
> >> Re: testing for Shellshock... would like your feedback... specifically,
> >>
On 10/9/14, 3:46 PM, Rick Karcich (rkarcich) wrote:
> Hello Chet,
>
> Re: testing for Shellshock... would like your feedback... specifically,
> regarding the possibility of human-directed combinatorial testing to find
> this Bash vulnerability...
>
> Given the knowl
On 10/9/14, 4:50 PM, Eduardo A. Bustamante López wrote:
> Second, once you generate a command, how will your test program know
> if it found a bug? It's easy when bash segfaults, but in the case of
> shellshock, it wasn't a crash.
This is the problem. It's hard to tell whether bash reporting a s
On 10/9/14, 6:06 PM, Pádraig Brady wrote:
> On 10/09/2014 08:46 PM, Rick Karcich (rkarcich) wrote:
>> Hello Chet,
>>
>> Re: testing for Shellshock... would like your feedback... specifically,
>> regarding the possibility of human-directed combinatorial testing to find
On 10/09/2014 08:46 PM, Rick Karcich (rkarcich) wrote:
> Hello Chet,
>
> Re: testing for Shellshock... would like your feedback... specifically,
> regarding the possibility of human-directed combinatorial testing to find
> this Bash vulnerability...
Sounds like how Michal Zal
wasn't the first one to notice
that, but he was the first one to realize the huge problem that this
represented.
Also, you have to find a way to isolate your machine/OS from the
testing, because bash has access to the file system, and other
things, that could destroy the operating system in t
Hello Chet,
Re: testing for Shellshock... would like your feedback... specifically,
regarding the possibility of human-directed combinatorial testing to find this
Bash vulnerability...
Given the knowledge about Shellshock that's been developed, I'm wanting to
define more of
On 8/14/13 4:41 PM, Jacek Krüger wrote:
> According to the manual of bash
> file1 -nt file2
> True if file1 is newer (according to modification date) than file2, or if
> file1 exists and file2 does not
>
> Bash is innacurate when testing modification dates. It ignores fractions
2013/8/14 Jacek Krüger
> Bash is innacurate when testing modification dates. It ignores fractions
> of a second. Is it expected? Coreutils test does it properly.
>
Looks like that is fixed in 4.3-alpha
http://git.savannah.gnu.org/cgit/bash.git/tree/CHANGES?h=devel#n554
--
Geir Hauge
According to the manual of bash
file1 -nt file2
True if file1 is newer (according to modification date) than file2, or
if file1 exists and file2 does not
Bash is innacurate when testing modification dates. It ignores fractions
of a second. Is it expected? Coreutils test does it properly
On 6/10/11 11:44 AM, Steven W. Orr wrote:
> As a work around, I can use eval or the builtin test, but my question is
> this: Is this a bug or is there a reason that it should work for arithmetic
> but not for the test [[ operator?
It's not a bug. The (( command is syntactic sugar: (( ...)) is ex
Andreas Schwab wrote:
"Steven W. Orr" writes:
As a work around, I can use eval or the builtin test, but my question is
this: Is this a bug or is there a reason that it should work for
arithmetic but not for the test [[ operator?
[[ is a reserved word like if, which triggers special parsing r
"Steven W. Orr" writes:
> As a work around, I can use eval or the builtin test, but my question is
> this: Is this a bug or is there a reason that it should work for
> arithmetic but not for the test [[ operator?
[[ is a reserved word like if, which triggers special parsing rules, so
you cannot
I am using arithmetic tests where the test operator is passed in as an arg and
it works just fine.
foo()
{
(( $1 $2 $3 ))
}
foo 5 '>' 7
But I figured that if this works for arithmetic, it should also work with the
test operator. It seems to not work:
514 > bar()
> {
> [[ $1 $2 ]]
ba
Le 17/02/2011 15:46, Eric Blake a écrit :
> On 02/16/2011 09:51 PM, Clark J. Wang wrote:
>> I know little about open source development process (and control?). I just
>> don't know where to get the bash code (like CVS, SVN respository) before
>> it's released. I think it's better to make it open to
On 2/17/11 10:46 AM, Eric Blake wrote:
> On 02/16/2011 09:51 PM, Clark J. Wang wrote:
>> I know little about open source development process (and control?). I just
>> don't know where to get the bash code (like CVS, SVN respository) before
>> it's released. I think it's better to make it open to mo
veryone can help review and test before a stable release.
There were alpha and beta releases to a testing group, and release
candidates that were publicly available. The release candidates
were actually discussed on bug-bash.
Chet
--
``The lyf so short, the craft so long to lerne.'' -
On 02/16/2011 09:51 PM, Clark J. Wang wrote:
> I know little about open source development process (and control?). I just
> don't know where to get the bash code (like CVS, SVN respository) before
> it's released. I think it's better to make it open to more people so
> everyone can help review and
efore
> > it's released. I think it's better to make it open to more people so
> > everyone can help review and test before a stable release.
>
> the 4.2 rc1 was announced on the list and garnered testing/feedback
>
Sorry I found no threads about 4.2 rc1 and rc2 was annouced only a few days
ago.
> -mike
>
--
Clark
ore people so
> everyone can help review and test before a stable release.
the 4.2 rc1 was announced on the list and garnered testing/feedback
-mike
signature.asc
Description: This is a digitally signed message part.
I know little about open source development process (and control?). I just
don't know where to get the bash code (like CVS, SVN respository) before
it's released. I think it's better to make it open to more people so
everyone can help review and test before a stable release.
--
Clark
On Mon, Apr 27, 2009 at 05:02:26PM +0300, Angel Tsankov wrote:
> I'd like to pipe the output from a command, say A, to another command, say
> B, then check if both commands completed successfully (i.e.with exist status
> 0)
PIPESTATUS
An array variable (see Arrays below) con
Hello!
I'd like to pipe the output from a command, say A, to another command, say
B, then check if both commands completed successfully (i.e.with exist status
0) and, if so, compare the standard output from command B to some string.
How can I do this in a bash script?
Regards,
Angel Tsankov
See this message? Fine. :)
Roman Rakus wrote:
Chet Ramey wrote:
2 when running scripts the script works, but get constant output of
TRACE: pid 7958: parse_and_execute: turned on CMD_IGNORE_RETURN from
comsub_ignore_return
TRACE: pid 7964: parse_and_execute: turned on CMD_IGNORE_RETURN from
comsub_ignore_return
TRACE: pi
Chet Ramey wrote:
2 when running scripts the script works, but get constant output of
TRACE: pid 7958: parse_and_execute: turned on CMD_IGNORE_RETURN from
comsub_ignore_return
TRACE: pid 7964: parse_and_execute: turned on CMD_IGNORE_RETURN from
comsub_ignore_return
TRACE: pid 7968: parse_and_ex
> 2 when running scripts the script works, but get constant output of
> TRACE: pid 7958: parse_and_execute: turned on CMD_IGNORE_RETURN from
> comsub_ignore_return
> TRACE: pid 7964: parse_and_execute: turned on CMD_IGNORE_RETURN from
> comsub_ignore_return
> TRACE: pid 7968: parse_and_execute:
2 Issues
1 configure script is not executable. Just had to chmod +x configure
2 when running scripts the script works, but get constant output of
TRACE: pid 7958: parse_and_execute: turned on CMD_IGNORE_RETURN from
comsub_ignore_return
TRACE: pid 7964: parse_and_execute: turned on CMD_IGNORE_R
test
___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash
76 matches
Mail list logo
