Re: Cygwin mount option -s is not supported

[Brian Inglis <Brian.Inglis@SystematicSw.ab.ca>]

On 2020-11-26 04:12, KAVALAGIOS Panagiotis (EEAS-EXT) wrote:
>> -----Original Message-----
>> From: Cygwin <cygwin-bounces@cygwin.com> On Behalf Of Brian Inglis
>> Sent: 25 November 2020 21:59
>>
>> On 2020-11-25 11:26, Vlado via Cygwin wrote:
>>> On 25.11.2020 15:18, KAVALAGIOS Panagiotis (EEAS-EXT) wrote:
>>
>> Mount -s was removed in 2008:
>> https://sourceware.org/git/?p=newlib-
>> cygwin.git;a=commitdiff;h=5f853b3fc5277da8cb5ba3ac7406447fe82e65de
>> three months after it was set to be ignored.
> 
> That explains the mystery. Thanks!
> 
>>>>     if [ -n "`uname -s |grep -i cygwin_`" ]; then
>>>>     # If we are on an new version of Cygnus we need to turn <letter>:/
>>>> in
>>>>     # the path to/cygdrive/<letter>/
>>
>> Use of 'Cygnus' refers to 20+ years ago when Cygwin was a product.
> 
> So, it might have been working quite "recently" then :)
> 
>>> Hard to say why Oracle's script is written this way. Standard Cygwin
>>> tool for file names conversion is cygpath. Instead of using sed, one
>>> can write WL_HOME_CYGWIN=`cygpath -u $WL_HOME`
>>> - simpler and the result will be more consistent. Example
>>>
>>> $ WL_HOME='C:\some\dir\subdir'            # Windows path $ echo
>>> "$WL_HOME" | sed "s#\([a-zA-Z]\):#/cygdrive/c/\1#g"
>>> /cygdrive/c/C\some\dir\subdir             # mixed forward and back
>>> slashes $ cygpath -u "$WL_HOME"
>>> /cygdrive/c/some/dir/subdir               # pretty Cygwin path
>>
>> Especially note the cygpath -U -> /proc/cygdrive/, -a -> /..., and -p path
>> conversion options should be used as appropriate: try all three!
> 
> Cygpath then is the correct approach to resolve this issue. I had no doubt about that. Anyway, this is not the only problem. They have messed the CLASSPATH as well and it needs to be updated to the correct libraries.

If you have an Oracle support contract, please submit a TAR, and attach any 
patches you make, to upstream support, to avoid having to keep making changes 
every update.

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.
[Data in binary units and prefixes, physical quantities in SI.]