A path that's invalid on 1.7 but presumably valid on 1.5

A path that's invalid on 1.7 but presumably valid on 1.5

[Lee Maschmeyer]

The invalid path in question: //?/e:cygwin/usr/share/tcl8.4/init.tcl. This 
is the path as supplied by tcl. To make it work, insert a / after the colon: 
//?/e:/cygwin/usr/share/tcl8.4/init.tcl.

Here's a Cygwin session that demonstrates this. I'm trying to build brltty, 
a program which is part of Cygwin but I'm building from the tarball. The 
path as supplied by tcl is invalid on 1.7. Since it worked on 1.5 it was 
presumably valid over there:

$ ./autogen
application-specific initialization failed: Can't find a usable init.tcl in 
the following directories:
    //?/e:/cygwin/share/tcl8.4 //?/e:cygwin/share/tcl8.4 
//?/e:cygwin/usr/share/tcl8.4 //?/e:share/tcl8.4 //?/e:cygwin/library //?/e
:library //?/e:../tcl8.4.1/library



This probably means that Tcl wasn't installed properly.

$ ls //?/e:cygwin/usr/share/tcl8.4/init.tcl
/bin/ls: cannot access //?/e:cygwin/usr/share/tcl8.4/init.tcl: No such file 
or directory
$ ls //?/e:/cygwin/usr/share/tcl8.4/init.tcl
//?/e:/cygwin/usr/share/tcl8.4/init.tcl

Note: I've checked with the brltty people and they assure me brltty isn't 
involved in any way.

HTH,

-- 
Lee Maschmeyer
Computing Center Services
Computing and Information Technology
Wayne State University
Detroit, Michigan, USA 



--
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: A path that's invalid on 1.7 but presumably valid on 1.5

[Corinna Vinschen]

On Jul 14 16:21, Lee Maschmeyer wrote:
> The invalid path in question: //?/e:cygwin/usr/share/tcl8.4/init.tcl. This 
> is the path as supplied by tcl. To make it work, insert a / after the 
> colon: //?/e:/cygwin/usr/share/tcl8.4/init.tcl.

Yes, that's right.  //?/e:cygwin is an invalid path.  I don't know
where the path with the missing slash comes from, but this looks
like an application or library bug.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

--
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: A path that's invalid on 1.7 but presumably valid on 1.5

[Lee Maschmeyer]

From: "Corinna Vinschen"
To: <cygwin@cygwin.com>
Sent: Monday, July 14, 2008 16:37
Subject: Re: A path that's invalid on 1.7 but presumably valid on 1.5


> On Jul 14 16:21, Lee Maschmeyer wrote:
>> The invalid path in question: //?/e:cygwin/usr/share/tcl8.4/init.tcl. 
>> This
>> is the path as supplied by tcl. To make it work, insert a / after the
>> colon: //?/e:/cygwin/usr/share/tcl8.4/init.tcl.
>
> Yes, that's right.  //?/e:cygwin is an invalid path.  I don't know
> where the path with the missing slash comes from, but this looks
> like an application or library bug.

Could it possibly be a path conversion error? Here's the error message; it 
looks possibly suspicious to me:

    //?/e:/cygwin/share/tcl8.4 //?/e:cygwin/share/tcl8.4 
//?/e:cygwin/usr/share/tcl8.4 //?/e:share/tcl8.4 //?/e:cygwin/library //?/e
:library //?/e:../tcl8.4.1/library

These are the 7 places where init.tcl is being searched. Notice that only 
the first has a slash after the colon. The second is the same as the first 
except with the slash missing, and the slash is missing after all of the 
other colons.

It's possible that whoever wrote the tcl (or whatever logic is involved) 
scripts just got lazy and quit including the slash, but that would be an 
explanation only if 1.5 didn't flag //?/e:cygwin as an error. I don't have a 
1.5 so can't check this.

At any rate, this isn't under my control as an end user. I wonder who needs 
to do what? This whole process worked without obvious error on 1.5.

Thanks very much,


-- 
Lee Maschmeyer
Computing Center Services
Computing and Information Technology
Wayne State University
Detroit, Michigan, USA 



--
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: A path that's invalid on 1.7 but presumably valid on 1.5

[Corinna Vinschen]

On Jul 15 10:49, Lee Maschmeyer wrote:
> From: "Corinna Vinschen"
> To: <cygwin@cygwin.com>
> Sent: Monday, July 14, 2008 16:37
> Subject: Re: A path that's invalid on 1.7 but presumably valid on 1.5
>
>
>> On Jul 14 16:21, Lee Maschmeyer wrote:
>>> The invalid path in question: //?/e:cygwin/usr/share/tcl8.4/init.tcl. 
>>> This
>>> is the path as supplied by tcl. To make it work, insert a / after the
>>> colon: //?/e:/cygwin/usr/share/tcl8.4/init.tcl.
>>
>> Yes, that's right.  //?/e:cygwin is an invalid path.  I don't know
>> where the path with the missing slash comes from, but this looks
>> like an application or library bug.
>
> Could it possibly be a path conversion error? Here's the error message; it 
> looks possibly suspicious to me:
>
>    //?/e:/cygwin/share/tcl8.4 //?/e:cygwin/share/tcl8.4 
> //?/e:cygwin/usr/share/tcl8.4 //?/e:share/tcl8.4 //?/e:cygwin/library //?/e
> :library //?/e:../tcl8.4.1/library

You could try to remove the /e mount point for testing.  It's possible
that the problem I patched yesterday is the cause of the problem.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

--
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: A path that's invalid on 1.7 but presumably valid on 1.5

[Lee Maschmeyer]

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

>You could try to remove the /e mount point for testing.  It's possible
>that the problem I patched yesterday is the cause of the problem.

No, that didn't help. I didn't reboot but I did restart Cygwin which I think 
is enough.

For completeness I'm attaching my fstab. Would it help if I change "some_fs" 
to ntfs?


-- 
Lee Maschmeyer
Computing Center Services
Computing and Information Technology
Wayne State University
Detroit, Michigan, USA 

[-- Attachment #2: fstab --]
[-- Type: application/octet-stream, Size: 3878 bytes --]

# The  file fstab contains descriptive information about the various file
# systems.  fstab is only read by programs, and not written;  it  is  the
# duty  of  the system administrator to properly create and maintain this
# file.  Each filesystem is described on a separate line; fields on  each
# line are separated by tabs or spaces.  Lines starting with '#' are com-
# ments.
#
# The first field, (fs_spec),  describes  the  block  special  device  or
# remote filesystem to be mounted.  On Cygwin, this is the native Windows
# path which  the mount point links in.  As path separator you MUST use a
# slash.  Usage of  a backslash might  lead to  unexpected  results.  UNC
# paths  (using  slashes,  not  backslashes)  are  allowed.  If  the path
# contains spaces these can be escaped as '\040'.
#
# The second field, (fs_file), describes the mount point for the filesys-
# tem.  If the  name  of  the  mount point contains  spaces these can be
# escaped as '\040'.
#
# The third field, (fs_vfstype), describes the type  of  the  filesystem.
# Cygwin supports any string here, since  the file system type is usually
# not  evaluated.  The  noticable  exception  is  the  file  system  type
# cygdrive.  This  type is  used to  set the  cygdrive  prefix.  See  the
# user's guide for more information about the cygdrive prefix.
#
# The  fourth  field, (fs_mntops), describes the mount options associated
# with  the filesystem.  It is  formatted as a  comma separated  list  of
# options.  It contains at least  the type of mount (binary or text) plus
# any additional options appropriate to  the filesystem type.  Recognized
# options are binary, text, nouser, user, exec, notexec, cygexec, nosuid,
# managed.  For a description of the options see  the user's guide.  Note
# that  nouser mount  points  are  not overridable  by  a  later  call to
# mount(2).  This is only  possible for user mount  points.  Mount points
# are by default nouser mount points, unless you specify the option user.
#
# The fifth (fs_freq) and sixth (fs_passno) field  are ignored.  They are
# so far only specified to keep a Linux-like fstab file layout.
#
# Note that  you don't have  to specify an fstab  entry for the root dir,
# unless you want  to have the  root dir pointing  to somewhere  entirely
# different (hopefully  you know what  you're doing), or  if you want  to
# mount the root dir with special options (for instance, as text mount).
#
# Example entries:
#
#   Just a normal mount point:
#
#       c:/foo /bar fat32 binary 0 0
#
#   A mount point for a managed, textmode mount:
#
#       C:/foo /bar/baz ntfs text,managed 0 0
#
#   A mount point for a Windows directory with spaces in it:
#
#       C:/Documents\040and\040Settings /docs ext3 binary 0 0
#
#   A mount point for a remote directory:
#
#       //server/share/subdir /srv/subdir smbfs binary 0 0
#
#   This is just a comment:
#
#       # This is just a comment
#
#   Set the cygdrive prefix to /mnt:
#
#       none /mnt cygdrive binary 0 0
#

e:/cygwin / some_fs binary 0 0
# a: /a some_fs binary,cygexec 0 0
c: /c some_fs binary,cygexec 0 0
d: /d some_fs binary,cygexec 0 0
e:/braille\040books /data/Braille\040Books some_fs binary,cygexec 0 0
e:/classic\040literature /data/Classic\040Literature some_fs binary,cygexec 0 0
e:/Jiffy-Braille /data/Jiffy-Braille some_fs binary,cygexec 0 0
e:/New\040Literature /data/New\040Literature some_fs binary,cygexec 0 0
# e: /e some_fs binary,cygexec 0 0
h: /h some_fs binary,cygexec 0 0
j: /j some_fs binary,cygexec 0 0
e:/cygwin/bin /usr/bin some_fs binary 0 0
e:/cygwin/lib /usr/lib some_fs binary 0 0
e:/cygwin/usr/X11R6/lib/X11/fonts /usr/X11R6/lib/X11/fonts some_fs binary 0 0
y: /y some_fs binary,cygexec 0 0
# This is default anyway:
# none /cygdrive cygdrive binary,user 0 0


[-- Attachment #3: Type: text/plain, Size: 218 bytes --]

--
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: A path that's invalid on 1.7 but presumably valid on 1.5

[Corinna Vinschen]

On Jul 15 14:00, Lee Maschmeyer wrote:
>> You could try to remove the /e mount point for testing.  It's possible
>> that the problem I patched yesterday is the cause of the problem.
>
> No, that didn't help. I didn't reboot but I did restart Cygwin which I 
> think is enough.
>
> For completeness I'm attaching my fstab. Would it help if I change 
> "some_fs" to ntfs?

No, the fs_vfstype field is basically ignored, except for the special
type "cygdrive".


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

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