Workaround for silent linkage errors
We seem to be getting a lot of messages along the lines of "I ran xyz and it did nothing." The typical response is something like "if you echo $? it is probably 53 which indicates a missing DLL." This usually gives rise to a further email asking where to get the missing DLL. Attached is a short script which should provide a workaround for the problem and hopefully reduce the mailing list traffic. It is designed to be installed in /etc/profile.d and uses one of two methods: 1) Use $PROMPT_COMMAND We can use the PROMPT_COMMAND envvar to do the checking for us. Although I use it myself, I imagine $PROMPT_COMMAND is a little- used bash feature, so very few users would override this in their own rc file, and will therefore get to see the message. I have made the variable read-only so that should a user want to override it, they'd have to take extra steps and in doing so would learn why it is set up that way. The definition of $PROMPT_COMMAND includes a comment, so that users echoing $PROMPT_COMMAND will be instructed to refer to /etc/profile.d/dllcheck.sh. It's by no means a perfect solution, because the error is only detected if the last command executed before the prompt failed. Most of the reported problems were related to running a single command, and not a command within a script, so this method should be fine for the majority of cases. 2) Trap the error This might be considered a better solution, as it also works inside functions (if set -E is used) and sourced scripts, but it has the disadvantage of printing the message twice if it was the last command in the script which failed - once as the error is trapped within the script, and once as the return status of the script is detected. Another potential problem with the second method is that scripts often trap errors themselves, and if such a script were sourced, it would leave the trap handler changed on exit, so this mechanism is more prone to being defeated. The file contains instructions on how to switch to the second method. I've lifted the copyright message from Eric Blake's 00bash.sh script, but essentially you're free to do whatever you like with it. I've only tested it under bash, so one modification you may wish to make is to ensure that it works (or at least does not cause other errors) when using shells other than bash. Phil dllcheck.sh Description: dllcheck.sh -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Workaround for silent linkage errors
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Phil Betts on 11/9/2007 10:15 AM:
>
> It is designed to be installed in /etc/profile.d and uses one of
> two methods:
>
> 1) Use $PROMPT_COMMAND
Won't work as posted, since profile.d is loaded by all bourne-style
shells, but 'declare -r' is bash-specific. Why not propose a patch for
/etc/profile in the base-files package instead, to change the default
cygwin prompt for new installations? And even if you want to keep this as
a profile.d script, at least do some sanity checking that you are only
installing it for bash.
> I have made
> the variable read-only so that should a user want to override it,
> they'd have to take extra steps and in doing so would learn why it
> is set up that way.
Yuck - since the variable is made read-only in a profile.d script, the
only way to undo that is to edit the profile.d script. Ouch. At least
allow for an environment variable override, rather than requiring editing
a system file.
>
> It's by no means a perfect solution, because the error is only
> detected if the last command executed before the prompt failed.
Have you looked into making your PROMPT_COMMAND use PIPESTATUS? For that
matter, I avoid PROMPT_COMMAND, and get all my exit statuses at once with
this PS1:
PS1='[EMAIL PROTECTED] \[\033[35m\]'\
'(${PIPESTATUS[*]}) \[\033[33m\]\w\[\033[0m\]\n\$ '
>
> This might be considered a better solution, as it also works inside
> functions (if set -E is used) and sourced scripts, but it has the
> disadvantage of printing the message twice if it was the last command
> in the script which failed - once as the error is trapped within the
> script, and once as the return status of the script is detected.
Ah, but you could have your trap change the return status to some other
failure value, so that the message doesn't print a second time. But you
are right that trapping ERR is prone to be lost in user scripts.
> I've lifted the copyright message from Eric Blake's 00bash.sh script,
Fine by me, since I lifted it from somewhere else (I think it was from the
GNU Coding Standards recommendations for how to make short files maximally
reusable while still declaring copyright, unlike what 'public domain'
achieves).
- --
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
iD8DBQFHOv6B84KuGfSFAYARAuWqAKCkjrziKAAuW1E53WDxR2jE6W/BmgCfd8ND
6iNlLKg2nMHTVGRzOikxH00=
=JHQU
-END PGP SIGNATURE-
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
RE: Workaround for silent linkage errors
Eric Blake wrote on Wednesday, November 14, 2007 1:56 PM::
> According to Phil Betts on 11/9/2007 10:15 AM:
If anyone missed this because of ultra paranoid virus filtering (it
had a .sh attachment), it's here:
http://cygwin.com/ml/cygwin/2007-11/msg00173.html
I didn't get a copy myself, but saw it was in the archives so didn't
re-post.
>> It is designed to be installed in /etc/profile.d and uses one of
>> two methods:
>>
>> 1) Use $PROMPT_COMMAND
>
> Won't work as posted, since profile.d is loaded by all bourne-style
> shells, but 'declare -r' is bash-specific.
I realise that. I just wanted to get the idea out there to gauge the
reaction before spending too long on a bullet-proof solution.
> Why not propose a patch
> for /etc/profile in the base-files package instead, to change the
> default cygwin prompt for new installations? And even if you want to
> keep this as a profile.d script, at least do some sanity checking
> that you are only installing it for bash.
Will do. You seem to imply that /etc/profile is only installed for
new installations. Is that correct? Given that a fair number of the
emails about this issue are from people who claim to have upgraded,
I'd prefer provide a solution that everyone will pick up.
Are there any other bourne-style shells apart from the following that
I should test with?
* ash
* bash
* pdksh
* bash-invoked-as-sh
I see you use /proc to detect the current shell. Is that the most
reliable way (for my purposes)? Whereas you are detecting if the
currently running shell is the file you are about to overwrite, my
purpose is to determine the shell's features. Would it be preferable
to test for some signature feature of each flavour rather than relying
on the name of the executable? If so, which tests would you recommend?
>> I have made
>> the variable read-only so that should a user want to override it,
>> they'd have to take extra steps and in doing so would learn why it
>> is set up that way.
>
> Yuck - since the variable is made read-only in a profile.d script, the
> only way to undo that is to edit the profile.d script. Ouch. At
> least allow for an environment variable override, rather than
> requiring editing a system file.
Fair point. I wrote it after receiving yet another email about exactly
the same issue as hundreds of others, so I was feeling a tad militant!
I've since been to my happy place so I'll incorporate the idea.
>> It's by no means a perfect solution, because the error is only
>> detected if the last command executed before the prompt failed.
>
> Have you looked into making your PROMPT_COMMAND use PIPESTATUS? For
> that matter, I avoid PROMPT_COMMAND, and get all my exit statuses at
> once with this PS1:
>
> PS1='[EMAIL PROTECTED] \[\033[35m\]'\
> '(${PIPESTATUS[*]}) \[\033[33m\]\w\[\033[0m\]\n\$ '
Learning something new every day - the advent of PIPESTATUS had slipped
under my radar. I'll investigate. I don't think you were suggesting I
should use PS1, but in case you were, I specifically wanted to avoid
using it as so many people change that. It might be worth using for the
other shell flavours though.
>> This might be considered a better solution, as it also works inside
>> functions (if set -E is used) and sourced scripts, but it has the
>> disadvantage of printing the message twice if it was the last command
>> in the script which failed - once as the error is trapped within the
>> script, and once as the return status of the script is detected.
>
> Ah, but you could have your trap change the return status to some
> other failure value, so that the message doesn't print a second time.
Another good point. I'll incorporate that too.
It'll probably be over a week before I get chance to do anything more
with this. If anyone has any other comments, now would be a good time
to raise them. I'd be particularly interested in similar solutions
for the other shell flavours.
Phil
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
