Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; 	charset="us-ascii"
Subject: RE: Workaround for silent linkage errors
Date: Wed, 14 Nov 2007 16:55:13 -0000
Message-ID: <2D9E96311DCA4C48BF185EA6928BC7BB02C01940@asc-mail.int.ascribe.com>
In-Reply-To: <473AFE81.8030900@byu.net>
From: "Phil Betts" <Phil DOT Betts AT ascribe DOT com>
To: <cygwin AT cygwin DOT com>
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Precedence: bulk
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Content-Transfer-Encoding: 8bit

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='\[\033[0m\]\n\[\033[32m\]\u@\h \[\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/