X-Recipient:	archive-cygwin AT delorie DOT com
X-SWARE-Spam-Status:	No, hits=-3.0 required=5.0 tests=AWL,BAYES_00,KHOP_THREADED,SPF_HELO_PASS,TW_CG,T_RP_MATCHES_RCVD
X-Spam-Check-By:	sourceware.org
To:	cygwin AT cygwin DOT com
From:	Andrew DeFaria <Andrew AT DeFaria DOT com>
Subject:	Re: Side-by-side configuration is incorrect reported as permission denied
Date:	Mon, 13 Aug 2012 07:59:09 -0700
Lines:	53
Message-ID:	<k0b4nt$rt6$1@dough.gmane.org>
References:	<k045k2$gvk$1 AT dough DOT gmane DOT org> <5025C431 DOT 7050201 AT cygwin DOT com> <CA+7connXxSSkw-fhHvqbVanEvX7YHOVVdLndmqmd07xRvFT49Q AT mail DOT gmail DOT com> <20120812170641 DOT GC32748 AT ednor DOT casa DOT cgf DOT cx> <CA+7conm=AXUX9Xfj67tGRgMbrgC47W9QHuQ2L3V2p_=7Cf81GQ AT mail DOT gmail DOT com> <CA+sc5m=myjskB4zG0HARWHvZMQGz-k=j7jT=q1Gny4XpNgMfCg AT mail DOT gmail DOT com> <k09mg3$52l$1 AT dough DOT gmane DOT org> <20120813082716 DOT GA11198 AT calimero DOT vinschen DOT de> <k0b35b$e99$1 AT dough DOT gmane DOT org> <20120813144247 DOT GH23253 AT calimero DOT vinschen DOT de>
Mime-Version:	1.0
User-Agent:	Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120714 Thunderbird/14.0
In-Reply-To:	<20120813144247.GH23253@calimero.vinschen.de>
X-IsSubscribed:	yes
Mailing-List:	contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id:	<cygwin.cygwin.com>
List-Unsubscribe:	<mailto:cygwin-unsubscribe-archive-cygwin=delorie DOT com AT cygwin DOT com>
List-Subscribe:	<mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive:	<http://sourceware.org/ml/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender:	cygwin-owner AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
Delivered-To:	mailing list cygwin AT cygwin DOT com

On 08/13/2012 07:42 AM, Corinna Vinschen wrote:
>>> There's a difference between cmd and Cygwin.  Cmd is a shell, Cygwin is
>>> just the underlying shared lib providing a generic API.
>> OK so bash...
> Ok so bash what?
You were saying cmd is a shell and Cygwin is a shared lib. So then 
perhaps the responsibility should fall to bash - a shell...
>>> If an error occurs, it's the shell's responsibility to print an error
>>> message in the first place.  All messages printed by Cygwin are not
>>> controllable by the calling application.  Therefore we usually only
>>> print messages from the DLL if something very serious happens from the
>>> DLLs perspective.  Some arbitrary Windows error code returned from
>>> CreateProcess is usually not something actually serious.  There was
>>> just "some" reason that an application couldn't be started.
>> IMHO "some" reason that the user should be alerted about. How is it
>> helpful to the end user to suppress the error message?
> Huh?  Somehow you swapping cause and effect.  There is no "suppressed"
> error message.  Generating an error message is the task of the shell in
> the first place.
There was an error message that cmd showed that bash did not. To me 
that's suppression.
> It's not that the OS generates an error message and cmd lets it slip
> through while Cygwin (or bash) "suppress" it.  It's the CreateProcess
> call which generates an error code ERROR_SXS_CANT_GEN_ACTCTX and cmd
> printing the connected error message, just like bash gets an error code
> EACCES and prints the connected error message "Permission denied".
Plumbing and mechanics aside, I'm just saying the user should be told 
the underlying problem. If ERROR_SXS_CANT_GEN_ACTCTX is the error code 
could ya at least print that as a string? It would give the user a 
fighting change and finding a solution...
>>> Also, where do you draw the border?  Which windows error code is serious
>>> enough to justify a (pretty intrusive!) error message from the underlying
>>> library and which isn't?
>> I would draw the border at "if there's an error message".
> Again, cause and effect turned upside down.
Not really. You seem stuck in thinking in only error codes - I'm 
thinking in solutions, regardless of the mechanics to get there. IOW the 
goal is to inform the user not only that an error occurred but what that 
errors was so that the user can fix it. How you accomplish that is not 
important (to me - speaking as an end user).

(Note: I understand the underlying issues somewhat - I'm just giving you 
a user's perspective).
>>> As cgf pointed out, Windows has zillions of error codes.  We wouldn't
>>> want to generate the same number of POSIX-like error codes.  It wouldn't
>>> make a lot of sense since POSIX applications only test for a limited,
>>> expected number of error codes, and it might break things.
>> I was talking error *messages* not error *codes*.
> Again, cause and effect turned upside down.
I don't think so.
-- 
Andrew DeFaria <http://defaria.com>
Why do you park in a driveway and drive on a parkway?


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

- Raw text -