fc -s ""="" "" segfaults in strsub()
Configuration Information [Automatically generated, do not change]: Machine: i486 OS: linux-gnu Compiler: gcc Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i486' -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i486-pc-linux-gnu' -DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/ locale' -DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -I. -I../bash -I../bash/include -I../bash/lib -g -O2 uname output: Linux sauna 2.6.18-4-k7 #1 SMP Wed May 9 23:42:01 UTC 2007 i686 GNU/Linux Machine Type: i486-pc-linux-gnu Bash Version: 3.1 Patch Level: 17 Release Status: release Description: Bash segfaults with the above command. GDB shows that the segfault happens in strsub(). I noticed this problem when I ran the saturn static analysis program ( http://saturn.stanford.edu/ ) against bash source code and it reported stringlib.c:173:red:Intraprocedural Null error stringlib.c:173:Possible NULL dereference of temp+templen Repeat-By: fc -s ""="" "" Fix: I don't know what the behavior of strsub() should be when both pat and rep are empty strings. Maybe it should just exit without doing any changes to the string?
Re: RFE: brace expansion sequences should do zero padding
Hi again!
I saw my first post made it to the list eventually as well. Sorry for
the duplicate. I hadn't realized that the newsgroup was moderated.
I'm a bit dishearted at the lack of response. On IRC many people pointed
out that usually this kind of issue can be solved by passing a sequence
to printf. Now I've come up with a real life example that isn't easy to
hack together using printf:
wget -x http://some.really.long/url/prefix/{,{000..123}.{html,jpg}}
There have been some concerns about changing the behaviour and thus
breaking existing scripts. The preferred solution in this case would be
to use "..." instead of ".." if one wanted to activate this feature.
Personally I believe that zero padded sequences in an existing
application that cares for the exact string and not only the numeric
value are so unlikely that adding another piece of syntax is not worth
the trouble, but I'd like your opinion on this.
Another thing worth mentioning is negative numbers. My padding pads all
numbers to a common width, not a common number of digits. This is what
printf does, and it's a wee little bit easier to implement. However it
could be changed to common number of digits as well. On IRC I got the
idea that {-07..003} should do common width, whereas {-007..003} should
do common number of digits. This, however, would add a lot of code. I
think negative numbers are so rare that they are not worth the effort.
Do you agree?
I hope to generate some feedback here. If you think this useful, tell me
about it, and I'll try a bit harder to get this into the offical
sources. If I get no single answer this time as well, I'll probably post
the patch somewhere online, patch my own version of bash, and that's it.
Greetings,
Martin von Gagern
signature.asc
Description: OpenPGP digital signature
Re: RFE: brace expansion sequences should do zero padding
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Martin von Gagern on 9/3/2007 2:16 PM:
>
> Another thing worth mentioning is negative numbers. My padding pads all
> numbers to a common width, not a common number of digits. This is what
> printf does, and it's a wee little bit easier to implement. However it
> could be changed to common number of digits as well. On IRC I got the
> idea that {-07..003} should do common width, whereas {-007..003} should
> do common number of digits. This, however, would add a lot of code. I
> think negative numbers are so rare that they are not worth the effort.
> Do you agree?
Perhaps rather than trying to improve bash {} expansion, you could use
coreutils seq instead. For example,
$ seq -f 'a/%03g' -007 003
a/-07
a/-06
a/-05
a/-04
a/-03
a/-02
a/-01
a/000
a/001
a/002
a/003
- --
Don't work too hard, make some time for fun as well!
Eric Blake [EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFG3HDN84KuGfSFAYARAgLOAJ45Ksjc9I5AxFSUAICNGl+2M0q4IACgjz5m
uSXIlLY4d+bCCCc76LC9NCs=
=LJhV
-END PGP SIGNATURE-
Re: RFE: brace expansion sequences should do zero padding
Eric Blake wrote:
> Perhaps rather than trying to improve bash {} expansion, you could use
> coreutils seq instead.
Hi Eric, thank's for taking an interest.
seq is not that much different from printf here, although I hadn't known
of its formatting capabilities. This changes nothing of the fact that
there are situations like the wget command in my last posting where
calling a subcommand isn't going to help much.
If I'd follow your argument, brace number sequences would not be needed
at all, as you can somehow use seq in most cases. However brace
sequences are part of bash, and for a good reason. For one they are a
lot easier to write than subcommand invocation, for a second you don't
have to worry so much about word splitting, and finally there are some
more complex cases where using a subcommand will make the command much
more complicated.
To give you another example, highlighting the word-splitting issue:
for i in $'This is record\n'{000..007}" of ${PWD}"; do
echo "> $i <"
done
OK, yes, I could add all that text inside the loop, but I believe you
can think of uses of word lists where this isn't so easy. As you can
see, the escape string introduces spaces and a newline, and the variable
may introduce arbitrary other characters. Together you have no obvious
save character at which you can split the output of any subprocess into
words. So word splitting now becomes a real problem, whereas with brace
expansion the world splitting is implicit.
Yes, I know, this as well can be solved using other tools, probably
together with bash arrays. However there will be a huge overhead. On the
other hand, brace expansion is intuitive, quick to write, easy to read,
and gets the job done - if the job doesn't need the zero padding, or you
apply my patch.
Greetings,
Martin von Gagern
signature.asc
Description: OpenPGP digital signature
