The attempt to build media-gfx/imagemagick with =app-shells/dash-0.5.6.1-r1 as /bin/sh ends up in a lot of errors as shown in the attached build log. The reason for them seems to be incorrectly generated magick-config.h file, which looks like a lot of: #ifndef MAGICKCORE_^A #define MAGICKCORE_^A^B #endif The same configure script works fine with =app-shells/dash-0.5.5.1.2 and app-shells/posh.
Created attachment 247318 [details] The build log
Created attachment 247320 [details] The resulting (broken) header file
Portage 2.2_rc81_p9 (default/linux/amd64/10.0/desktop, gcc-4.4.4, glibc-2.12.1-r1, 2.6.36-rc3-pomiocik+ x86_64) ================================================================= System Settings ================================================================= System uname: Linux-2.6.36-rc3-pomiocik+-x86_64-Intel-R-_Pentium-R-_Dual_CPU_T2330_@_1.60GHz-with-gentoo-2.0.1 Timestamp of tree: Tue, 14 Sep 2010 15:00:01 +0000 ccache version 2.4 [disabled] app-shells/bash: 4.1_p7 dev-java/java-config: 2.1.11 dev-lang/python: 2.4.6, 2.5.4-r4, 2.6.5-r3, 2.7.1_pre20100912::python, 3.0.1::python, 3.1.3_pre20100912::python, 3.2_pre20100815::python dev-util/ccache: 2.4-r8 dev-util/cmake: 2.8.1-r2 sys-apps/baselayout: 2.0.1 sys-apps/openrc: 9999 sys-apps/sandbox: 2.3-r1 sys-devel/autoconf: 2.13, 2.67 sys-devel/automake: 1.9.6-r3, 1.10.3, 1.11.1 sys-devel/binutils: 2.20.1-r1 sys-devel/gcc: 4.4.4-r1 sys-devel/gcc-config: 1.4.1 sys-devel/libtool: 2.2.10 sys-devel/make: 3.81-r2 virtual/os-headers: 2.6.35 (sys-kernel/linux-headers) ACCEPT_KEYWORDS="amd64 ~amd64" ACCEPT_LICENSE="* -@EULA" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-march=core2 -O2 -pipe" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/share/X11/xkb" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/env.d/java/ /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo /etc/texmf/language.dat.d /etc/texmf/language.def.d /etc/texmf/updmap.d /etc/texmf/web2c" CXXFLAGS="-march=core2 -O2 -pipe" DISTDIR="/usr/local/portage/distfiles" EMERGE_DEFAULT_OPTS="--ask --keep-going" FEATURES="assume-digests collision-protect distlocks fixlafiles fixpackages news parallel-fetch preserve-libs protect-owned sandbox sfperms sign strict unknown-features-warn unmerge-logs unmerge-orphans userfetch userpriv usersandbox usersync" GENTOO_MIRRORS="http://distfiles.gentoo.org" LANG="pl_PL.UTF-8" LC_ALL="pl_PL.UTF-8" LDFLAGS="-Wl,-O1 -Wl,--as-needed -Wl,--hash-style=gnu" LINGUAS="" MAKEOPTS="-j3" PKGDIR="/usr/local/portage/packages" PORTAGE_CONFIGROOT="/" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --times --compress --force --whole-file --delete --stats --timeout=45 --exclude=/distfiles --exclude=/packages --exclude=/local" PORTAGE_TMPDIR="/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/portage/local/gamerlay /usr/portage/local/games /usr/portage/local/java-overlay /usr/portage/local/kde-sunset /usr/portage/local/qting-edge /usr/portage/local/x11 /usr/portage/local/perl-experimental /usr/portage/local/python /usr/portage/local/sunrise /usr/portage/local/science /usr/portage/local/gnome /home/mgorny/git/emdzientoo" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="X a52 aac acl acpi alsa amd64 avahi bash-completion bluetooth branding bzip2 cairo caps cdr cli consolekit cracklib crypt cups curl cxx dbus dirac directfb djvu dri dts dvd dvdr emboss encode exif expat fam fbcon fftw filecaps firefox flac fontconfig fortran gd gdbm gif gmp gnome-keyring gnutls gpm graphviz gtk iconv icu idn imagemagick ipv6 java6 jbig jpeg jpeg2k kate lapack lcms libedit libnotify libproxy mad matroska mikmod mmap mmx mmxext mng modules mp3 mp4 mpeg mtp mudflap multilib ncurses nptl nptlonly ogg opencore-amr openexr opengl openmp pam pango pch pcre pdf perl png ppds pppd python qt3support qt4 raw readline reflection schroedinger sdl session slang smp sndfile speex spell sse sse2 ssl ssse3 startup-notification svg sysfs tcpd theora threads tiff timidity truetype unicode usb v4l2 vcd vim-syntax vorbis wavpack wifi wmf x264 xcb xcomposite xml xorg xpm xulrunner xv xvid zlib" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mmap_emul mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache cgi cgid dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" ELIBC="glibc" INPUT_DEVICES="evdev synaptics" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" RUBY_TARGETS="ruby18 ruby19" SANE_BACKENDS="artec_eplus48u" USERLAND="GNU" VIDEO_CARDS="fbdev r300 r600 radeon vesa" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p iface geoip fuzzy condition tee tarpit sysrq steal rawnat logmark ipmark dhcpmac delude chaos account" Unset: CPPFLAGS, CTARGET, FFLAGS, INSTALL_MASK, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS ================================================================= Package Settings ================================================================= media-gfx/imagemagick-6.6.3.0 was built with the following: USE="X autotrace bzip2 corefonts cxx djvu fftw fontconfig fpx graphviz gs hdri jbig jpeg jpeg2k lcms lqr (multilib) openexr openmp perl png raw svg tiff truetype wmf xml zlib -q32 -q8 -static-libs" VIDEO_CARDS="-nvidia" app-shells/dash-0.5.5.1.2 was built with the following: USE="(multilib) -libedit -static"
Sorry, once again: app-shells/dash-0.5.6.1-r1 was built with the following: USE="(multilib) -libedit -static"
i dont think it's specific to imagemagick. the broken code in question isnt coming from imagemagick; it's autogenerated from autoconf. basically do: echo \\1 dash will show the wrong answer
(In reply to comment #5) > basically do: echo \\1 > > dash will show the wrong answer That's not a bug. Backslashes in echo are not portable in POSIX sh, and have always worked this way in dash. imagemagick needs fixing.
again, this code isnt coming from imagemagick. specifically, the breaking the config.h is from AX_PREFIX_CONFIG_H: http://www.gnu.org/software/autoconf-archive/ax_prefix_config_h.html however, even libtool uses this construct: symxfrm="\\1 $ac_symprfx\\2 \\2" while you can try the "echo isnt portable" angle, it doesnt mean dash isnt being a huge pile of crap. the spec is clear that octals start with a 0, not just any number. and dash itself is inconsistent -- \\8 and \\9 do what it should: output \8 and \9. but \\1 up to \\7 output octal values. this isnt a new bug to dash though as you point out. it's just that newer features in dash make autoconf think the active shell isnt a pile of crap (LINENO and such), and so it sticks with it instead of running a real shell (like bash). that is why this stuff falls apart with newer dash. so the fix should be simple ... only have dash do octal sequences when it starts with "\\0".
(In reply to comment #7) > again, this code isnt coming from imagemagick. specifically, the breaking the > config.h is from AX_PREFIX_CONFIG_H: > http://www.gnu.org/software/autoconf-archive/ax_prefix_config_h.html Fair enough, but AX_PREFIX_CONFIG_H is not installed by autoconf, not widely used outside of imagemagick, and is included in imagemagick's source directory. Incidentally, the comments at the bottom of the file note this as a bug, but not with the right way to fix this (see below). > however, even libtool uses this construct: > symxfrm="\\1 $ac_symprfx\\2 \\2" It doesn't use it with echo. Backslashes in string literals are valid, but if you want to print them, use printf. > while you can try the "echo isnt portable" angle, it doesnt mean dash isnt > being a huge pile of crap. the spec is clear that octals start with a 0, not > just any number. and dash itself is inconsistent -- \\8 and \\9 do what it > should: output \8 and \9. but \\1 up to \\7 output octal values. No, the relevant part of the spec is "string A string to be written to standard output. If the first operand is -n, or if any of the operands contain a backslash ( '\' ) character, the results are implementation-defined." The spec goes on to define certain escape sequences that XSI systems must support, but other sequences are still implementation-defined and nonportable. > this isnt a new bug to dash though as you point out. it's just that newer > features in dash make autoconf think the active shell isnt a pile of crap > (LINENO and such), The fact that dash isn't bash doesn't make it a pile of crap. > and so it sticks with it instead of running a real shell > (like bash). that is why this stuff falls apart with newer dash. > > so the fix should be simple ... only have dash do octal sequences when it > starts with "\\0". No, autoconf already knows the right and portable way to print strings containing backslashes, and makes this available with AS_ECHO. imagemagick (and copied code from autoconf-archive) simply needs to use it.
imagemagick isnt the only package that uses that macro. it's just the first one noticed. libtool will sometimes `echo` that variable in which case dash will screw it up. because dash pointlessly deviates from the defacto shell implementation makes it a piece of crap. changing random packages all over the tree and dealing with arbitrary (and probably unnoticed) breakage is a waste of time. what actually makes sense is to change dash's echo to not be moronic.
hell, even debian has dropped dash-0.5.6+ also, read dash's own manual. it does not document \\# as being an octal sequence. it documents \\0#. in dash(1) and echo(1). and read dash's own code. it tries to support this but fails because it merged printf and echo a little too much. echocmd -> conv_escape_str -> string octal constants are not like those in C; They start with a \0, ....
You're putting words in my mouth. Don't do that. If you want to continue this discussion, feel free to e-mail, but I'm just going to reassign this to graphics@ as this is an acknowledged bug in AX_PREFIX_CONFIG_H, regardless of whether dash is being stupid. I'll provide a patch soon.
I fail to see how this is imagemagick bug, moving to dash maintainers, get the shell fixed
i didnt put words in your mouth. i never said "you said xxx". i just said i disagree with your interpretation of things and dash sucks. as i already clearly outlined, dash itself says this should be working which means dash needs to be fixed.
Created attachment 247500 [details, diff] patch for imagemagick I suggested private mail to avoid bugspam, but apparently that isn't appreciated. (In reply to comment #9) > libtool will sometimes `echo` that variable in which case dash will screw it up. Admittedly true, but only into a log file, not in any way that actually breaks things, or it wouldn't have gone unnoticed. > because dash pointlessly deviates from the defacto shell implementation makes it a piece of crap. "The defacto shell implementation" only makes sense for Gentoo/Linux. Once you look at Gentoo/Alt, there is no de facto shell implementation. And dash behaviour goes back at least five years. It's not as if dash suddenly out of the blue decided to go and break things. > changing random packages all over the tree and dealing with arbitrary (and probably unnoticed) breakage is a waste of time. In almost all cases -- this may be an exception -- what breaks with dash is going to break with FreeBSD sh as well. So no, it's not a waste of time, even if you think dash is crap. > what actually makes sense is to change dash's echo to not be moronic. Since current behaviour has a long history and is not in violation of any specs, good luck with that. (In reply to comment #10) > hell, even debian has dropped dash-0.5.6+ dash 0.5.6 was a bad release and broke at least the build of glibc. You should know that already. But considering that bug went without any comment from the maintainer, maybe nobody bothered to read it. > also, read dash's own manual. it does not document \\# as being an octal > sequence. it documents \\0#. in dash(1) and echo(1). echo(1) is irrelevant, that's the coreutils documentation. dash(1) doesn't document \1 explicitly, but states "all other backslash sequences elicit undefined behaviour". > and read dash's own code. it tries to support this but fails because it merged printf and echo a little too much. I'm familiar with dash's code, TYVM. The comment explains why \0377 must be accepted, but doesn't say \377 must be rejected. Nobody said that but you, and you have nothing to show for it other than "bash doesn't do it either". (In reply to comment #12) > I fail to see how this is imagemagick bug, moving to dash maintainers, get the shell fixed As I already explained, the current dash behaviour, regardless of whether it is sane, is permitted by POSIX, so regardless of whether dash is going to get changed, imagemagick should be fixed to either work with any POSIX sh, or hack autoconf to force bash from its configure script. (In reply to comment #13) > i didnt put words in your mouth. i never said "you said xxx". You said "imagemagick isnt the only package that uses that macro." which is either irrelevant or putting words in my mouth. I gave you the benefit of the doubt. When I said it wasn't _widely_ used outside of imagemagick, I checked. It isn't. > as i already clearly outlined, dash itself says this should be working which means dash needs to be fixed. dash _is_ working. That's a simple fact not affected by your name-calling.
BTW, the autoconf documentation says to simply avoid all backslashes in echo: -- Macro: AS_ECHO (WORD) Emits WORD to the standard output, followed by a newline. WORD must be a single shell word (typically a quoted string). The bytes of WORD are output as-is, even if it starts with "-" or contains "\". Redirections can be placed outside the macro invocation. This is much more portable than using `echo' (*note Limitations of Shell Builtins: echo.). `echo' The simple `echo' is probably the most surprising source of portability troubles. It is not possible to use `echo' portably unless both options and escape sequences are omitted. Don't expect any option. Do not use backslashes in the arguments, as there is no consensus on their handling. For `echo '\n' | wc -l', the `sh' of Solaris outputs 2, but Bash and Zsh (in `sh' emulation mode) output 1. The problem is truly `echo': all the shells understand `'\n'' as the string composed of a backslash and an `n'. Within a command substitution, `echo 'string\c'' will mess up the internal state of ksh88 on AIX 6.1 so that it will print the first character `s' only, followed by a newline, and then entirely drop the output of the next echo in a command substitution. Because of these problems, do not pass a string containing arbitrary characters to `echo'. For example, `echo "$foo"' is safe only if you know that FOO's value cannot contain backslashes and cannot start with `-'. If this may not be true, `printf' is in general safer and easier to use than `echo' and `echo -n'. Thus, scripts where portability is not a major concern should use `printf '%s\n'' whenever `echo' could fail, and similarly use `printf %s' instead of `echo -n'. For portable shell scripts, instead, it is suggested to use a here-document like this: cat <<EOF $foo EOF Alternatively, M4sh provides `AS_ECHO' and `AS_ECHO_N' macros which choose between various portable implementations: `echo' or `print' where they work, `printf' if it is available, or else other creative tricks in order to work around the above problems.
splitting conversations across e-mail and bugzilla makes no sense. it does make sense to keep it all in one place (bugzilla). read the generated configure code. if the active shells sucks (like dash), it will resort to finding a sane one (starting with bash). so yes, bash is still defacto implementation on many Gentoo/Alt platforms. if you want to push that patch to the upstream maintainer of ax_prefix_config_h.m4, then feel free. the contact information is readily available. i never said dash changed behavior. in fact, i explicitly said "this isnt a new bug to dash". it however doesnt mean that bugs should be ignored just because they've been around for a long time. it is a waste of time *for us to look into this* since it isnt fixing anything. if you want to go on a portability quest beyond Gentoo on your own time, that is your business. yes, i know dash sucks. and i dont generally bother commenting on dash bugs because it is a huge pita and brings a lot more crap baggage with it than possibly offset any meager benefits. i'm not its maintainer on purpose. no, echo(1) is not irrelevant. try actually reading the source of dash. here, i'll point out actual paths since you arent doing it yourself: git clone <dash repo> man ./src/bltin/echo.1 nano ./src/bltin/printf.c
however, maybe i missed something, but why exactly are we talking about this octal crap anyways ? we arent doing: echo \1 we're doing: echo \\1 and the documentation everywhere says "\\ output a backslash". so dash is wrongly doubly consuming backslashes. i could care less about the octal behavior of doing: echo \123 (ignoring that even dash itself says it shouldnt be doing an octal and it differs from bash)
Created attachment 247502 [details, diff] dash-echo-octal.patch simple patch to dash to not have echo treat \1 as octal
(In reply to comment #16) > splitting conversations across e-mail and bugzilla makes no sense. it does > make sense to keep it all in one place (bugzilla). But this discussion is not interesting for anyone who just wants imagemagick working. > read the generated configure code. if the active shells sucks (like dash), it > will resort to finding a sane one (starting with bash). so yes, bash is still > defacto implementation on many Gentoo/Alt platforms. By "suck", you of course mean "does not support LINENO", which is irrelevant as FreeBSD sh also supports LINENO. > if you want to push that patch to the upstream maintainer of > ax_prefix_config_h.m4, then feel free. the contact information is readily > available. I was pushing this to the imagemagick maintainer, because imagemagick is failing with a correct shell. > i never said dash changed behavior. in fact, i explicitly said "this isnt a > new bug to dash". it however doesnt mean that bugs should be ignored just > because they've been around for a long time. You continue to refer to this as a bug. It isn't. When you accept that the current behaviour is valid, the fact that dash has done this for a long time does matter: you shouldn't change dash behaviour just because it is different from what you're used to, you should only change dash behaviour if the current behaviour is broken. > it is a waste of time *for us to look into this* since it isnt fixing anything. You don't have to go look into this, so you don't have to waste any time. > if you want to go on a portability quest beyond Gentoo on your own time, that > is your business. imagemagick is coming from the portage tree. So is dash. So is FreeBSD sh. (You didn't forget about Gentoo/*BSD, did you?) How is any of this beyond Gentoo? > yes, i know dash sucks. and i dont generally bother commenting on dash bugs > because it is a huge pita and brings a lot more crap baggage with it than > possibly offset any meager benefits. i'm not its maintainer on purpose. > no, echo(1) is not irrelevant. try actually reading the source of dash. here, > i'll point out actual paths since you arent doing it yourself: > git clone <dash repo> > man ./src/bltin/echo.1 I was checking out the installed documentation, I hadn't considered the possibility of one of the dash-provided manpages getting installed while another isn't. But again, that page says \0377 is accepted and prints one character. It doesn't say \377 prints the same character. It doesn't say \377 prints four characters either. The other manpage you mentioned explicitly does not guarantee any specific behaviour for \377. > nano ./src/bltin/printf.c I was reading that when I wrote my previous comment. (In reply to comment #17) > however, maybe i missed something, but why exactly are we talking about this > octal crap anyways ? we arent doing: > echo \1 > we're doing: > echo \\1 > and the documentation everywhere says "\\ output a backslash". \\ means \ before it even gets to echo, unless it appears in single quotes. echo '\\1' correctly prints two characters (plus a newline). echo '\\1' equally correctly prints three characters with bash.
by "suck", i'm not talking just LINENO. i mean in general it's been a pile. looks to me like dash is broken: $ dash -c 'strace -eexecve echo \\012' execve("/bin/echo", ["echo", "\\012"], [/* 69 vars */]) = 0 \012 $ dash -c 'echo \\012' | hexdump -C 00000000 0a 0a |..|
(In reply to comment #20) > by "suck", i'm not talking just LINENO. i mean in general it's been a pile. Missing LINENO support was the one thing missing from dash that made configure scripts prefer bash. So if more than just LINENO, what did you mean by "if the active shells sucks (like dash), it will resort to finding a sane one (starting with bash)"? > looks to me like dash is broken: > > $ dash -c 'strace -eexecve echo \\012' > execve("/bin/echo", ["echo", "\\012"], [/* 69 vars */]) = 0 > \012 > > $ dash -c 'echo \\012' | hexdump -C > 00000000 0a 0a |..| This only demonstrates that coreutils's echo behaviour matches that of bash in this case. I'm not sure if the strace output was confusing, but /bin/echo's argv[1] consisted of four characters, the first of which was escaped by strace before being printed. $ bash -c 'strace -eexecve echo \\012' execve("/bin/echo", ["echo", "\\012"], [/* 45 vars */]) = 0 \012
(In reply to comment #21) Sorry, I was missing your point. bash's and coreutils's echo don't recognise escape sequences at all by default (you need -e for that), dash's does. In that case, dash is conforming to the spec for XSI-conforming systems, and bash and coreutils aren't. You've already provided the link, but you can also check echo(1p).
(In reply to comment #16) > if you want to push that patch to the upstream maintainer of > ax_prefix_config_h.m4, then feel free. the contact information is readily > available. from my pov, push the change to autoconf-archive's ax_prefix_config_h.m4 maintainer. then push that to imagemagick maintainers. then I have no problem carrying it in our imagemagick package while waiting for inclusion from upstream, being dash's fault or not. but for sure we aren't going to be carrying this just in gentoo, working around one package, with fix not pushed forward. running autotools is a pita in imagemagick, avoiding it at any cost. patching configure directly can only be a short time solution.
ok, that's a good point. so we're back to \\1...\\7. in Gentoo, i guess we'll do this: - drop dash-0.5.6.1-r1 from the tree - update dash-0.5.5.1.2 to dash-0.5.5.1.7 (to match Debian) - apply the octal patch i posted here if you want to pursue the other changes outside of Gentoo, go for it. i dont think we should be pointlessly hassling our devs over useless build bugs that dont manifest in our systems.
Created attachment 247514 [details, diff] dash-echo-octal-2.patch this shrinks the dash code and lets it follow its own intentions
(In reply to comment #23) > from my pov, push the change to autoconf-archive's ax_prefix_config_h.m4 > maintainer. then push that to imagemagick maintainers. then I have no problem > carrying it in our imagemagick package while waiting for inclusion from > upstream, being dash's fault or not. but for sure we aren't going to be > carrying this just in gentoo, working around one package, with fix not pushed > forward. I have no problem with that, and have reported this to the autoconf-archive folks. I'll wait till it's committed there to bring it to imagemagick. > running autotools is a pita in imagemagick, avoiding it at any cost. patching > configure directly can only be a short time solution. The patch already attached here modifies the configure script directly too. (In reply to comment #24) > ok, that's a good point. so we're back to \\1...\\7. in Gentoo, i guess we'll > do this: > - drop dash-0.5.6.1-r1 from the tree What the hell? When dash was actually breaking things, you did nothing, and now that dash is behaving properly, you want to get rid of it? No. > - update dash-0.5.5.1.2 to dash-0.5.5.1.7 (to match Debian) It's a good idea to add that regardless of any other issues. > - apply the octal patch i posted here Again, no, don't do that, unless you get that approved upstream. > if you want to pursue the other changes outside of Gentoo, go for it. i dont > think we should be pointlessly hassling our devs over useless build bugs that > dont manifest in our systems. Who do you mean by "our"?
like i already told you, i could give two sh*ts when dash is broken and isnt affecting other packages. but when it makes people wrongly spend time changing other packages, then i'm interested. this is that case. i'm getting rid of dash 0.5.6 because Debian has punted it too. i could care less if upstream dash takes this change. it's going into Gentoo.
vapier, you're claiming that you don't give a shit whether dash upstream wants that patch, but at the same time pushing that patch because that's dash's intended behaviour. You're lying at this point. I don't accept that from you or anyone else.
why dont you try reading my comment closer before making wrong statements. i dont care when a broken dash isnt affecting other people. it'll get fixed eventually by someone. but you're attempting to "fix" other packages instead of dash. that is when i'm interested in keeping dash's crap to itself.
That doesn't require pushing your crap, nor does it require removing dash 0.5.6. The former because since dash 0.5.5 and lower don't support LINENO anyway, so they don't need any changes for echo '\1', because the configure scripts won't be run with dash anyway, the latter because it's even less work to mask it than it is to remove it. But you don't even need to mask it, because the /bin/sh -> dash link isn't the default anyway. And you're completely ignoring the point that other people will run into the same problems, and they don't need to overwrite system symlinks to see the breakage. Stop this. Seriously.
ive punted 0.5.6.x (to keep in sync with Debian). ive also added 0.5.5.1.7 with my aforementioned octal patch. if you wish to take it upstream to get it fixed in a different way, feel free. http://sources.gentoo.org/app-shells/dash/files/dash-0.5.5.1-octal.patch?rev=1.1 further, refer once again to the code and documentation i highlighted. dash itself looks like it is trying to only support \0 for octal sequences. the fact that it supports more looks like an accidental bug. also, you might want to refrain from making things personal. i never once made a personal comment about you here. i said *dash* sucks.
(In reply to comment #31) > also, you might want to refrain from making things personal. i never once made > a personal comment about you here. i said *dash* sucks. I didn't say you sucked. I said you were lying. Big difference. "You suck" is an insult. "You're lying" is a statement of fact, considering I demonstrated that you were in fact lying. Please note that I have now re-read your messages in case I misinterpreted them. The exact sentences I objected to: Comment #25: this shrinks the dash code and lets it follow its own intentions Comment #27: i could care less if upstream dash takes this change. I will not be continuing this here, but I will reiterate that I'm not going to accept this crap.
no, you didnt. all you demonstrated was an inability to understand. the comments you highlighted do not show a "lie". you arent the dash upstream nor downstream maintainer, so it really doesnt matter if you "accept" this change. once again, feel free to pursue echo changes with the relevant upstream projects, but Gentoo maintainers need not worry themselves with this crap.
