On Monday 23 February 2009 07:31, Antonio Macchi wrote:
>>
>> Yes, it's ok. Posix says that printf field widths are specified in
>> number of bytes.
>>
>
> I've never red nothing about POSIX,
You should, especially if posting here something like that.
> but imho, in the past, "char" and
>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Mike Frysinger on 2/22/2009 10:03 PM:
> previous versions of bash would happily accept negative values ( treated as a
> signed integer and masked with like 0xff), but it seems some changes related
> to option parsing has broken that
>
>
Introduction
The first public release of bash-4.0 is now available with the URLs
ftp://ftp.cwru.edu/pub/bash/bash-4.0.tar.gz
ftp://ftp.gnu.org/pub/gnu/bash/bash-4.0.tar.gz
and from the usual GNU mirror sites.
Unlike previous bash distributions, this tar file includes the formatted
The first public release of the GNU Readline library, version 6.0,
is now available for FTP with the URLs
ftp://ftp.cwru.edu/pub/bash/readline-6.0.tar.gz
ftp://ftp.gnu.org/pub/gnu/readline/readline-6.0.tar.gz
and from the usual GNU mirror sites.
This distribution is essentially a standalone vers
Mike Frysinger wrote:
> previous versions of bash would happily accept negative values ( treated as a
> signed integer and masked with like 0xff), but it seems some changes related
> to option parsing has broken that
>
> $ f(){ return -1; }; f
> -bash: return: -1: invalid option
> return: usage:
On Monday 23 February 2009 07:50:30 Eric Blake wrote:
> According to Mike Frysinger on 2/22/2009 10:03 PM:
> > previous versions of bash would happily accept negative values ( treated
> > as a signed integer and masked with like 0xff), but it seems some changes
> > related to option parsing has bro
On Monday 23 February 2009 08:48:32 Chet Ramey wrote:
> Mike Frysinger wrote:
> > previous versions of bash would happily accept negative values ( treated
> > as a signed integer and masked with like 0xff), but it seems some changes
> > related to option parsing has broken that
> >
> > $ f(){ retur
Hi All - If I want to write a script that uses ftp to transfer a file and
then, only after the file has been successfully transferred, I do something
else - how do I tell my script to wait until the ftp is finished before
doing the next command? Is that even possible?
--
View this message in cont
DanSandbergUCONN wrote:
Hi All - If I want to write a script that uses ftp to transfer a file and
then, only after the file has been successfully transferred, I do something
else - how do I tell my script to wait until the ftp is finished before
doing the next command? Is that even possible?
Mike Frysinger wrote:
> On Monday 23 February 2009 08:48:32 Chet Ramey wrote:
>> Mike Frysinger wrote:
>>> previous versions of bash would happily accept negative values ( treated
>>> as a signed integer and masked with like 0xff), but it seems some changes
>>> related to option parsing has broken
On Monday 23 February 2009 10:53:06 Chet Ramey wrote:
> Mike Frysinger wrote:
> > On Monday 23 February 2009 08:48:32 Chet Ramey wrote:
> >> Mike Frysinger wrote:
> >>> previous versions of bash would happily accept negative values (
> >>> treated as a signed integer and masked with like 0xff), but
DanSandbergUCONN wrote:
> Hi All - If I want to write a script that uses ftp to transfer a file and
> then, only after the file has been successfully transferred, I do something
> else - how do I tell my script to wait until the ftp is finished before
> doing the next command? Is that even possibl
Mike Frysinger wrote:
>> Are filenames beginning with a `-' useless because `rm' interprets
>> them as option arguments when, for instance, they're generated by the
>> expansion of `*'? Is `rm' broken for interpreting them as options?
>> I mean, there's no real difference between the two cases.
On Monday 23 February 2009 15:16:21 Chet Ramey wrote:
> Mike Frysinger wrote:
> >> Are filenames beginning with a `-' useless because `rm' interprets
> >> them as option arguments when, for instance, they're generated by the
> >> expansion of `*'? Is `rm' broken for interpreting them as options?
>
i was going through the new features list in NEWS to see what cool things are
in here and i saw the new checkjobs option. is it just me or does this cause
a non-login bash to crash at exit which leads to an infinite loop / cpu
churning ?
$ gdb bash
(gdb) r
vap...@vapier 0:0 bash-4.0 $ shopt -s
I normally wrap the builtin cd into a function cd, which does some
additional things and then calls the builtin. Example:
function cd
{
local list=$(echo *.bui)
# ...
builtin cd "$1"
}
I have a PS1 like this:
PS1="\\w \$ "
With bash 3, this worked well; cd-
Mike Frysinger wrote:
> i was going through the new features list in NEWS to see what cool things are
> in here and i saw the new checkjobs option. is it just me or does this cause
> a non-login bash to crash at exit which leads to an infinite loop / cpu
> churning ?
I can't reproduce this. D
On Monday 23 February 2009 18:05:26 Chet Ramey wrote:
> Mike Frysinger wrote:
> > i was going through the new features list in NEWS to see what cool things
> > are in here and i saw the new checkjobs option. is it just me or does
> > this cause a non-login bash to crash at exit which leads to an i
Chet Ramey wrote:
> p...@arcturus.universe wrote:
>
>> Bash Version: 4.0
>> Patch Level: 0
>> Release Status: release
>>
>> Description:
>> Problem with auto completion :
>> ls[space][TAB]
>> gives the follwing abort :
>> malloc: /Users/chet/src/bash/src/parse.y:5561: assertion botched
>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Chet Ramey on 2/23/2009 1:16 PM:
> OK. Let me try to explain how the current behavior derives from Posix.
>
> It falls under two parts of the standard (section 1.4):
>
> 1. Unless otherwise stated in the utility description, when given
Mike Frysinger wrote:
> On Monday 23 February 2009 18:05:26 Chet Ramey wrote:
>> Mike Frysinger wrote:
>>> i was going through the new features list in NEWS to see what cool things
>>> are in here and i saw the new checkjobs option. is it just me or does
>>> this cause a non-login bash to crash at
Bernd Eggink wrote:
> I normally wrap the builtin cd into a function cd, which does some
> additional things and then calls the builtin. Example:
>
>function cd
>{
> local list=$(echo *.bui)
> # ...
> builtin cd "$1"
>}
>
> I have a PS1 like this:
>
>PS1="\\w \$ "
On Monday 23 February 2009 23:00:31 Chet Ramey wrote:
> Mike Frysinger wrote:
> > On Monday 23 February 2009 18:05:26 Chet Ramey wrote:
> >> Mike Frysinger wrote:
> >>> i was going through the new features list in NEWS to see what cool
> >>> things are in here and i saw the new checkjobs option. i
bash.bug
Description: Binary data
Everytime I entered `cd ' it would aborted:
malloc: /Users/chet/src/bash/src/parse.y:5561: assertion botched
free: called with unallocated block argument
last command: q
Aborting...Aborted
My system:
# uname -a
Linux ubuntu606 2.6.15-51-386 #1 PREEMPT Tue Feb 12 16:52:52 UTC 2008 i686
GNU/Linux
25 matches
Mail list logo
