This is the mail archive of the crossgcc@sourceware.org mailing list for the crossgcc project.
See the CrossGCC FAQ for lots more information.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
Hello Martin! Hello All! (re-sent, the previous one got HTML formatted by some ways unknown to me, and rightfully rejected by sourceware.org. Sorry for the noise, Martin). On Monday 07 July 2008 14:00:39 Martin Guy wrote: > On 7/7/08, Martin Guy <martinwguy@yahoo.it> wrote: > > The best answer is to remove bashisms > There's a debian perl script checkbashisms which can help with this > (if it matters). Will try. > I've run it over the scripts and there are a dozen or so trivial > bashisms that are not necessary. The only script that should be POSIXly correct is the configure script. The others explictly require bash 3.0 or above. ./configure checks that this is the case, and refuses to configure if not. Unfortunately, there are certain constructs in the _build_ scripts that require bashisms (eg. retrieving the exit status of any command in a pipe). > Unfortunately it's not clear enough > from the code what you are trying to achieve in certain places, like > . tsocks > where tsocks is neither a shell function nor a local shell script. Hmmm. I know there are almost no documentaion about the internals at the moment. It is on my TODO, but it's a long road before I get anything usable (and understandable!). > Do you happen to know that it's implemented as a shell script on your > system and think to save a millisecond? If tsocks does not exist, '.' will yield an non-zero return code, and that will be trapped by the 'set -E', the error "handler" will get executed, and the build process will just stop right at that point. Anyway, in this particular situation, there is a check for tsocks availablity for each code path that uses tsocks: CT_HasOrAbort tsocks Furthermore, the tsocks option in the ocnfiguration menu is marked as being EXPERIMENTAL, and users selecting this option get warned if they read the help entry: [--SNIP--] If you think you do not know what tsocks is, or how to configure it, chances are that you do not need to set this option. And I don't buy arguments that states that users don't read the help! :-) > Does tsocks need to set shell > variables in the same environment that are then picked up in the > parent program? Does it matter if tsocks happens to use the same local > variable name as CT and modifies them at random? Variables that matters in crosstool-NG ought to be prefixed with "CT_". And I do know what tsocks does: it sets LD_PRELOAD. > ${CT_PROXY_TYPE/socks} > which doesn't conform to anything in the bash manual. Yes it does. The manual explicitly states, in the section dealing with "Parameter Expansion": If string is null, matches of pattern are deleted and the / following pattern may be omitted. The bash manual lies on the table beside my bed, and I read a chapter every evening, just before I switch the lights off... Just kidding! Hehe! :-) > The bash > implementation I tried it on behaves the same as bash's > ${CT_PROXY_TYPE/socks/} i.e., turn the first occurrence of "socks" > into "" if it exists. That's the intended behavior (see above). > I'd code that some otherway, or at least say > what that piece of code is supposed to achieve. Point taken! :-) > Given puzzles like these I'm not confident to just fix them and send > patches, regarding these constructs as obscure puzzles to bu guessed > at rather than the lucid form of communication to other programmers > that code should be :) It would not come to my mind to look at Fortran code. I don't speak Fortran. My point is that to work with bash scripts, one must know bash scripting (no offense meant!). :-) I do explicitly use bashisms, of which some I consider as being features that fit my needs. The script are explicit bash scripts, as they do use #!/bin/bash, and not the standard #!/bin/sh. (One may object that bash may be in another place than /bin/bash). On the other hand, you are right that the code lacks documentation, or at least some comments near the tricky parts. I will do a sanitising pass on the configure script, as this one shall be POSIXly correct, and will try to add some comments in the build scripts, where it is necessary, or change the code so it is more readable. I'm planning a 1.2.0 release and the associated maintenance branch shortly, and I don't know if I will have the time to investigate those issues prior to releasing, though... Please feel free to send patches commenting those parts you find tricky! :-) > However, I attach the latest version of the checkbashisms perl script > in case this is useful. The only thing you use that's hard to get > round portably is "echo -n", though there is a portable hack defining > a shell fn echo_n() in the good article on shell portability > http://www.linux.com/articles/34658 Nice pointer! Instructive. Regards, and many thanks again for your input! Yann E. MORIN. -- .-----------------.--------------------.------------------.--------------------. | Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: | | +0/33 662376056 | Software Designer | \ / CAMPAIGN | ^ | | --==< °_° >==-- °------------.-------: X AGAINST | /e\ There is no | | http://ymorin.is-a-geek.org/ | * _ * | / \ HTML MAIL | """ conspiracy. | °------------------------------°-------°------------------°--------------------° -- For unsubscribe information see http://sourceware.org/lists.html#faq
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |