RE: Is this supposed to work this way?

RE: Is this supposed to work this way?

[Buchbinder, Barry (NIH/NIAID) [E]]

Andrey Repin sent the following at Tuesday, April 03, 2012 3:21 PM
>[Z:\]$ assoc .sh
>.sh=unixshell.script
>
>[Z:\]$ ftype unixshell.script
>unixshell.script="C:/Programs/Cygwin/bin/env.exe" "%1" %*
>
>[Z:\]$ testcase.sh
>++ readlink -fn 'Z:\testcase.sh'
>+ XXX='/z/Z:\testcase.sh'
>+ echo '/z/Z:\testcase.sh'
>/z/Z:\testcase.sh
>++ dirname '/z/Z:\testcase.sh'
>+ XXX=/z/Z:
>+ echo /z/Z:
>/z/Z:
>+ ls -l /z/Z:
>ls: cannot access /z/Z:: No such file or directory
>
>The "testcase.sh" is very simple.
>
>#! /bin/sh
>set -x
>XXX=${XXX:=$(readlink -fn "$0")}
>echo $XXX
>XXX=$(dirname "$XXX")
>echo $XXX
>ls -l "$XXX"
>
>I can combat this by
>XXX=$(cygpath -alm "$0")
>XXX=${XXX:=$(readlink -fn "$0")}
>
>but then my script losing portability. (Namely, I can't "set -e" it then.)
>Any suggestions, perhaps?

Is there a reason that something like the following wouldn't work?

if [ -f /bin/cygwin1.dll ]
then
else
fi

>Sorry for my terrible english...

Not at all terrible.

Best wishes,

- Barry
  Disclaimer: Statements made herein are not made on behalf of NIAID.

--
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

Re: Is this supposed to work this way?

[Andrey Repin]

Greetings, Buchbinder, Barry (NIH/NIAID) [E]!

> Is there a reason that something like the following wouldn't work?

> if [ -f /bin/cygwin1.dll ]

Hm. Turned out, this is more reliable check, than
test "$OSTYPE" = "cygwin" && ...

But, oh, so much for consistency...

Question to Cygwin staff: shouldn't $OSTYPE be declared for Cygwin programs,
even if they are not started from Cygwin shell? Is this at all possible?


--
WBR,
Andrey Repin (anrdaemon@freemail.ru) 04.04.2012, <04:44>

Sorry for my terrible English...


--
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

Re: Is this supposed to work this way?

[Eric Blake]

[-- Attachment #1: Type: text/plain, Size: 918 bytes --]

On 04/03/2012 06:47 PM, Andrey Repin wrote:
> Greetings, Buchbinder, Barry (NIH/NIAID) [E]!
> 
>> Is there a reason that something like the following wouldn't work?
> 
>> if [ -f /bin/cygwin1.dll ]
> 
> Hm. Turned out, this is more reliable check, than
> test "$OSTYPE" = "cygwin" && ...
> 
> But, oh, so much for consistency...
> 
> Question to Cygwin staff: shouldn't $OSTYPE be declared for Cygwin programs,
> even if they are not started from Cygwin shell? Is this at all possible?

No, not possible - $OSTYPE is not standardized, so there's no point in
expecting cygwin to provide it (of course, you can export it in your
~/.bashrc).  Furthermore, even if cygwin exported it, the moment your
cygwin process starts a non-cygwin process, that process would also see
the same setting.

-- 
Eric Blake   eblake@redhat.com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 620 bytes --]

Re: Is this supposed to work this way?

[Andrey Repin]

Greetings, Eric Blake!

>>> Is there a reason that something like the following wouldn't work?
>> 
>>> if [ -f /bin/cygwin1.dll ]
>> 
>> Hm. Turned out, this is more reliable check, than
>> test "$OSTYPE" = "cygwin" && ...
>> 
>> But, oh, so much for consistency...
>> 
>> Question to Cygwin staff: shouldn't $OSTYPE be declared for Cygwin programs,
>> even if they are not started from Cygwin shell? Is this at all possible?

> No, not possible - $OSTYPE is not standardized, so there's no point in
> expecting cygwin to provide it (of course, you can export it in your
> ~/.bashrc).  Furthermore, even if cygwin exported it, the moment your
> cygwin process starts a non-cygwin process, that process would also see
> the same setting.

That raises another question: what is the standard way of detecting OS type?
uname -o
?


--
WBR,
Andrey Repin (anrdaemon@freemail.ru) 04.04.2012, <05:34>

Sorry for my terrible english...


--
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

Re: Is this supposed to work this way?

[Warren Young]

On 4/3/2012 7:35 PM, Andrey Repin wrote:
>
> what is the standard way of detecting OS type?
> uname -o
> ?

The wise try not to do that at all.

Instead, take in a little wisdom from the people who created autoconf, a 
piece of software that's been uncommonly successful[*] by FOSS 
standards: don't test for platforms, test for features.

The reason is, platform feature sets change.  When you write software 
that makes decisions based on platforms, it tends to break when those 
changes happen.  Or, nearly as bad, your software continues to use some 
workaround that eventually becomes unnecessary when the platform fixes 
the problem that lead you to create the workaround.

It's the latter case I'd worry about here.

What's happening is that because you're launching the shell script 
through some Windows-native mechanism (double-clicking it in Explorer, 
maybe?) it's getting a Windows style path in $0.  Maybe cygwin1.dll will 
one day detect that situation and translate the path automatically.

The way I'd suggest you attack the problem is do a regex match on $0 to 
see if it looks like a Windows path, then run it through cygpath if so. 
  "^[A-Z]:/" is probably a good enough test; it's unlikely to ever match 
a path your script gets on other platforms.

A false positive would require that someone be *trying* to create an 
MS-DOS style path system on a *ix box, something far to ooky to believe 
has ever happened.  But then, people are strange.

Resist the temptation to back up the path style test with a platform 
test like the [ -f /bin/cygwin1.dll ] suggested by Barry.  If the path 
looks like a Windows path, have the backbone to just send the path 
blindly through cygpath.  If ever you run into a situation where cygpath 
doesn't exist but the path matches your regex, fix the regex or add a 
secondary feature test, don't resort to platform detection.


[*] I think it's fair to say Autoconf's only real competition is ad hockery.

--
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

Re: Is this supposed to work this way?

[Csaba Raduly]

Hi all!

On Wed, Apr 4, 2012 at 5:57 AM, Warren Young  wrote:
> On 4/3/2012 7:35 PM, Andrey Repin wrote:
>>
>>
>> what is the standard way of detecting OS type?
>> uname -o
>> ?
>
>
> The wise try not to do that at all.
>
> Instead, take in a little wisdom from the people who created autoconf, a
> piece of software that's been uncommonly successful[*] by FOSS standards:
> don't test for platforms, test for features.
>
(snip)

May I suggest a gold star for this explanation  ?

Csaba
-- 
GCS a+ e++ d- C++ ULS$ L+$ !E- W++ P+++$ w++$ tv+ b++ DI D++ 5++
The Tao of math: The numbers you can count are not the real numbers.
Life is complex, with real and imaginary parts.
"Ok, it boots. Which means it must be bug-free and perfect. " -- Linus Torvalds
"People disagree with me. I just ignore them." -- Linus Torvalds

--
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

Re: Is this supposed to work this way?

[Andrey Repin]

Greetings, Warren Young!

>> what is the standard way of detecting OS type?
>> uname -o
>> ?

> The wise try not to do that at all.

> Instead, take in a little wisdom from the people who created autoconf, a 
> piece of software that's been uncommonly successful[*] by FOSS 
> standards: don't test for platforms, test for features.

Well, then, following your wisdom, I have to clog every line of my script with
"... || exit" or an equivalent.

Because even an attempt to continue execution, if any error occured, would be
disastrous to the calling program.
Solution is to "set -e" and have script bail out at any problem, but if I try
autoconf approach and blindly run whatever I feel appropriate, hoping for the
best and preparing for worst, I won't have such option.


--
WBR,
Andrey Repin (anrdaemon@freemail.ru) 04.04.2012, <12:57>

Sorry for my terrible english...


--
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

Re: Is this supposed to work this way?

[Eric Blake]

[-- Attachment #1: Type: text/plain, Size: 1860 bytes --]

On 04/04/2012 03:01 AM, Andrey Repin wrote:

> 
> Well, then, following your wisdom, I have to clog every line of my script with
> "... || exit" or an equivalent.

No, you don't.  You can factor out your feature checks up front, in a
way that still works with 'set -e', rather than having to give up 'set
-e' through the entire script.  That said...

> 
> Because even an attempt to continue execution, if any error occured, would be
> disastrous to the calling program.
> Solution is to "set -e" and have script bail out at any problem,

'set -e' is a can of worms, best avoided if you don't want surprises.
Consider:

f() { set -e; false; echo hi; }
f || echo bye

It does NOT exit on the false.  Rather, it prints 'hi' and NOT 'bye',
all while turning on set -e for the rest of your script.  And that
behavior is mandated by POSIX.  My opinion is that you are better off
coding without 'set -e' in the first place.

> but if I try
> autoconf approach and blindly run whatever I feel appropriate, hoping for the
> best and preparing for worst, I won't have such option.

Give us more details of a feature you're trying to test.  I'll even get
you started with an example - suppose you want to know when to use cygpath:

if (cygpath --version) >/dev/null 2>&1; then
  my_convert() { cygpath "$1"; }
else
  my_convert() { echo "$1"; }
fi

foo "$(my_convert "$file")"

which will run cygpath on $file on cygwin, and will use $file unchanged
on other platforms.  And there you have a feature check - you checked
the feature of whether cygpath exists as an executable up front, then
the rest of your script is now OS-independent by relying on your
up-front setup based on the results of the feature check.

-- 
Eric Blake   eblake@redhat.com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 620 bytes --]

Re: Is this supposed to work this way?

[Warren Young]

On 4/4/2012 7:29 AM, Eric Blake wrote:
> On 04/04/2012 03:01 AM, Andrey Repin wrote:
>
>> Well, then, following your wisdom, I have to clog every line of my script with
>> "... || exit" or an equivalent.
>
> No, you don't.  You can factor out your feature checks up front,

This.

Maybe I'm misreading your problem, Andrey, but I got the impression from 
your STC that all it would take to fix it is to translate passed-in 
paths at the start of the script, if needed.  Everything that follows 
could then treat the paths portably.

Where is this error-checks-on-every-line horror?  I don't see how it 
emerges from your STC.

Simple test cases are great as far as they go, but maybe you've 
oversimplified this one, so I'm solving the toy problem posed by the 
STC, while entirely missing the actual problem.

--
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

Re: Is this supposed to work this way?

[Andrey Repin]

Greetings, Eric Blake!

>> Well, then, following your wisdom, I have to clog every line of my script with
>> "... || exit" or an equivalent.

> No, you don't.  You can factor out your feature checks up front, in a
> way that still works with 'set -e', rather than having to give up 'set
> -e' through the entire script.  That said...

>> 
>> Because even an attempt to continue execution, if any error occured, would be
>> disastrous to the calling program.
>> Solution is to "set -e" and have script bail out at any problem,

> 'set -e' is a can of worms, best avoided if you don't want surprises.
> Consider:

> f() { set -e; false; echo hi; }
> f || echo bye

> It does NOT exit on the false.  Rather, it prints 'hi' and NOT 'bye',
> all while turning on set -e for the rest of your script.  And that
> behavior is mandated by POSIX.  My opinion is that you are better off
> coding without 'set -e' in the first place.

Well, this is interesting...

>> but if I try
>> autoconf approach and blindly run whatever I feel appropriate, hoping for the
>> best and preparing for worst, I won't have such option.

> Give us more details of a feature you're trying to test.  I'll even get
> you started with an example - suppose you want to know when to use cygpath:

> if (cygpath --version) >/dev/null 2>&1; then
>   my_convert() { cygpath "$1"; }
> else
>   my_convert() { echo "$1"; }
> fi

> foo "$(my_convert "$file")"

For provided STC, that would be enough. But the script I've striped it from is
reassembling Java application file. And if any step of preparation would fail,
it should not try to assemble it. The difference between Cygwin/Linux/Mac is
just the first stop in there.
I'll have to think about that some day, when I don't have a headache.
May be make OS-specific checks before blowing the horn, if I don't find more
elegant solution... (As I said already, I've hit a stall with readlink on Mac.)

> which will run cygpath on $file on cygwin, and will use $file unchanged
> on other platforms.  And there you have a feature check - you checked
> the feature of whether cygpath exists as an executable up front, then
> the rest of your script is now OS-independent by relying on your
> up-front setup based on the results of the feature check.



--
WBR,
Andrey Repin (anrdaemon@freemail.ru) 06.04.2012, <02:20>

Sorry for my terrible english...


--
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

RE: Is this supposed to work this way?

[Nellis, Kenneth]

From: Andrey Repin

> That raises another question: what is the standard way of detecting OS
type?
> uname -o
> ?

The Wikipedia article on uname indicates which platforms
support uname's -o option.
http://en.wikipedia.org/wiki/Uname
--Ken Nellis

--
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

Is this supposed to work this way?

[Andrey Repin]

Greetings, All!

[Z:\]$ assoc .sh
.sh=unixshell.script

[Z:\]$ ftype unixshell.script
unixshell.script="C:/Programs/Cygwin/bin/env.exe" "%1" %*

[Z:\]$ testcase.sh
++ readlink -fn 'Z:\testcase.sh'
+ XXX='/z/Z:\testcase.sh'
+ echo '/z/Z:\testcase.sh'
/z/Z:\testcase.sh
++ dirname '/z/Z:\testcase.sh'
+ XXX=/z/Z:
+ echo /z/Z:
/z/Z:
+ ls -l /z/Z:
ls: cannot access /z/Z:: No such file or directory



The "testcase.sh" is very simple.

#! /bin/sh
set -x
XXX=${XXX:=$(readlink -fn "$0")}
echo $XXX
XXX=$(dirname "$XXX")
echo $XXX
ls -l "$XXX"

I can combat this by
XXX=$(cygpath -alm "$0")
XXX=${XXX:=$(readlink -fn "$0")}

but then my script losing portability. (Namely, I can't "set -e" it then.)
Any suggestions, perhaps?


-- 
WBR,
Andrey Repin (anrdaemon@freemail.ru) 03.04.2012, <23:10>

Sorry for my terrible english...


--
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

Re: Is this supposed to work this way?

[Andrey Repin]

Greetings, Andrey Repin!

> Any suggestions, perhaps?

Nevermind it, please. I forgot about Mac OS systems. They don't support
readlink pointing to non-links at all.


--
WBR,
Andrey Repin (anrdaemon@freemail.ru) 04.04.2012, <02:39>

Sorry for my terrible english...


--
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