From: UnixOS2 Archive To: "UnixOS2 Archive" Date: Thu, 27 Feb 2003 04:54:06 EST-10EDT,10,-1,0,7200,3,-1,0,7200,3600 Subject: [UnixOS2_Archive] No. 57 ************************************************** Wednesday 26 February 2003 Number 57 ************************************************** Subjects for today 1 Re: u:/bin/sh: ../u:/unixos2/bin/install.exe: not found : John Poltorak 2 Re: TFTPD : jimburke200 at earthlink.net (James E. Burke Jr.) 3 Re: u:/bin/sh: ../u:/unixos2/bin/install.exe: not found : John Poltorak 4 Re: TFTPD : jimburke200 at earthlink.net (James E. Burke Jr.) 5 Re: u:/bin/sh: ../u:/unixos2/bin/install.exe: not found : John Poltorak 6 Re: u:/bin/sh: ../u:/unixos2/bin/install.exe: not found : Stefan Neis 7 Re: TFTPD : jimburke200 at earthlink.net (James E. Burke Jr.) 8 IMAPD : John Poltorak 9 Re: u:/bin/sh: ../u:/unixos2/bin/install.exe: not found : John Poltorak 10 Re: u:/bin/sh: ../u:/unixos2/bin/install.exe: not found : Holger Veit 11 Re: u:/bin/sh: ../u:/unixos2/bin/install.exe: not found : Holger Veit 12 Re: u:/bin/sh: ../u:/unixos2/bin/install.exe: not found : Holger Veit 13 Re: u:/bin/sh: ../u:/unixos2/bin/install.exe: not found : John Poltorak 14 Re: u:/bin/sh: ../u:/unixos2/bin/install.exe: not found : Stefan Neis 15 Re: u:/bin/sh: ../u:/unixos2/bin/install.exe: not found : Stefan Neis 16 TFTPD : John Poltorak 17 Re: TFTPD : John Poltorak 18 Re: TFTPD : John Poltorak **= Email 1 ==========================** Date: Thu, 27 Feb 2003 10:59:38 +0000 From: John Poltorak Subject: Re: u:/bin/sh: ../u:/unixos2/bin/install.exe: not found On Wed, Feb 26, 2003 at 09:14:18PM +0100, Andreas Buening wrote: > Holger Veit wrote: > > > > On Wed, Feb 26, 2003 at 10:24:25AM +0000, John Poltorak wrote: > > > > > > Why does this sort of thing happen:- > > > > > > u:/bin/sh: ../u:/unixos2/bin/install.exe: not found > > [snip] > > > It is a problem of the "full pathname" which is set in > > argv[0] by EMX. > > Could you be a bit more specific, please? What I'd like to know is why this command is invoked with some apps, whilst others run install.exe without any problem by invoking it directly rather than through /bin/sh. I guess it must be something in the Makefile.... The error above occurs when building RECODE but I have also seen it in other apps. > Bye, > Andreas > > -- > One OS to rule them all, One OS to find them, > One OS to bring them all and in the darkness bind them > In the Land of Mordor where the Shadows lie. -- John **= Email 2 ==========================** Date: Thu, 27 Feb 2003 12:11:51 -0800 From: jimburke200 at earthlink.net (James E. Burke Jr.) Subject: Re: TFTPD I have an IBM version of TFTP Server that juns under java. I don't recall where I found it, but it's small and I'd be glad to email it to you. >I'm trying to boot Linux remotely using something called PXELINUX and I >need a TFTP server which supports 'tsize'. > >Apparently IBM's program doesn't. > >There is some ported app on Hobbes which claims it does support the >required option, but the only docs are the source code and I have no idea >how it is supposed to work... It doesn't seem to transfer the requested >file, but I can't tell whether the program is broken or if I just haven't >started it properly... > > >Is anyone familiar with TFTPD and the 'tsize' option? > >TFTP-HPA has been recommended as a suitable server. I'm wondering if there >is any chance of being able to build it on OS/2... > > >-- >John > > > > **= Email 3 ==========================** Date: Thu, 27 Feb 2003 12:22:27 +0000 From: John Poltorak Subject: Re: u:/bin/sh: ../u:/unixos2/bin/install.exe: not found On Thu, Feb 27, 2003 at 12:56:22PM +0100, Stefan Neis wrote: > On Thu, 27 Feb 2003, John Poltorak wrote: > > > What I'd like to know is why this command is invoked with some apps, > > whilst others run install.exe without any problem by invoking it directly > > rather than through /bin/sh. > > > > I guess it must be something in the Makefile.... > > Some makefiles probably explicitly set SHELL=/bin/sh somewhere and others > don't ... I don't think that could be the reason. I've just looked at two Makefiles and both set SHELL to u:/bin/sh, but they set INSTALL differently. One (RECODE) set it thus:- INSTALL = ../u:/unixos2/bin/install.exe The other (TEXINFO) like this:- INSTALL = u:/unixos2/bin/install.exe I don't know why it should be different. Maybe I need to look at Makefile.in or Makefile.am for a reason... > HTH, > Stefan > -- > Micro$oft is not an answer. It is a question. The answer is 'no'. > -- John **= Email 4 ==========================** Date: Thu, 27 Feb 2003 12:31:02 -0800 From: jimburke200 at earthlink.net (James E. Burke Jr.) Subject: Re: TFTPD From the FAQ: What is the maximum file size that I can send or receive? It depends on your client and the server. The TFTP protocol itself uses a counter which overflows at 32 megabytes. Most clients and servers can't handle this condition. This TFTP server, however, handles this condition; so the limitation is based on the filesystem of the server platform. >On Thu, Feb 27, 2003 at 12:11:51PM -0800, James E. Burke Jr. wrote: >> I have an IBM version of TFTP Server that juns under java. >> I don't recall where I found it, but it's small and I'd be glad to >> email it to you. > >Do you know if if supports 'tsize' ? > >> >I'm trying to boot Linux remotely using something called PXELINUX and I >> >need a TFTP server which supports 'tsize'. >> > >> >Apparently IBM's program doesn't. >> > >> >There is some ported app on Hobbes which claims it does support the >> >required option, but the only docs are the source code and I have no idea >> >how it is supposed to work... It doesn't seem to transfer the requested >> >file, but I can't tell whether the program is broken or if I just haven't >> >started it properly... >> > >> > >> >Is anyone familiar with TFTPD and the 'tsize' option? >> > >> >TFTP-HPA has been recommended as a suitable server. I'm wondering if there >> >is any chance of being able to build it on OS/2... > > >-- >John > > > > **= Email 5 ==========================** Date: Thu, 27 Feb 2003 12:38:36 +0000 From: John Poltorak Subject: Re: u:/bin/sh: ../u:/unixos2/bin/install.exe: not found On Thu, Feb 27, 2003 at 12:22:27PM +0000, John Poltorak wrote: > On Thu, Feb 27, 2003 at 12:56:22PM +0100, Stefan Neis wrote: > > On Thu, 27 Feb 2003, John Poltorak wrote: > > > > > What I'd like to know is why this command is invoked with some apps, > > > whilst others run install.exe without any problem by invoking it directly > > > rather than through /bin/sh. > > > > > > I guess it must be something in the Makefile.... > > > > Some makefiles probably explicitly set SHELL=/bin/sh somewhere and others > > don't ... > > I don't think that could be the reason. I've just looked at two Makefiles > and both set SHELL to u:/bin/sh, but they set INSTALL differently. > > One (RECODE) set it thus:- > > INSTALL = ../u:/unixos2/bin/install.exe Having looked into it a little deeper... The above setting only exists within Makefiles in subdirectories of RECODE. The value in Makefile in the parent directory is fine. So, whatever is adding the '../' is at fault. I guess that would be something in the configure script... > > HTH, > > Stefan > > -- > > Micro$oft is not an answer. It is a question. The answer is 'no'. -- John **= Email 6 ==========================** Date: Thu, 27 Feb 2003 12:56:22 +0100 (CET) From: Stefan Neis Subject: Re: u:/bin/sh: ../u:/unixos2/bin/install.exe: not found On Thu, 27 Feb 2003, John Poltorak wrote: > What I'd like to know is why this command is invoked with some apps, > whilst others run install.exe without any problem by invoking it directly > rather than through /bin/sh. > > I guess it must be something in the Makefile.... Some makefiles probably explicitly set SHELL=/bin/sh somewhere and others don't ... HTH, Stefan -- Micro$oft is not an answer. It is a question. The answer is 'no'. **= Email 7 ==========================** Date: Thu, 27 Feb 2003 14:10:08 -0800 From: jimburke200 at earthlink.net (James E. Burke Jr.) Subject: Re: TFTPD >On Thu, Feb 27, 2003 at 12:31:02PM -0800, James E. Burke Jr. wrote: >> From the FAQ: >> >> What is the maximum file size that I can send or receive? >> It depends on your client and the server. The TFTP protocol itself uses a >> counter which overflows at 32 megabytes. Most clients and servers can't >> handle this condition. This TFTP server, however, handles this condition; so >> the limitation is based on the filesystem of the server platform. > > >If it doesn't specifically mention 'tsize' I suppose it won't support it. > > >-- >John TFTP was on alphaworks but now is listed as "Graduated"...whatever that might mean. There is this item in the documentation: getMaxPacketSize public int getMaxPacketSize() That was the only hit on "tsize". **= Email 8 ==========================** Date: Thu, 27 Feb 2003 14:36:29 +0000 From: John Poltorak Subject: IMAPD Has anyone set up the IMAP server which comes with the latest release of Pine? It's something I'm hoping to set up soon, but I would like to know how straightforward a process it is. -- John **= Email 9 ==========================** Date: Thu, 27 Feb 2003 15:04:43 +0000 From: John Poltorak Subject: Re: u:/bin/sh: ../u:/unixos2/bin/install.exe: not found On Thu, Feb 27, 2003 at 03:52:57PM +0100, Holger Veit wrote: > On Thu, Feb 27, 2003 at 12:38:36PM +0000, John Poltorak wrote: > > > One (RECODE) set it thus:- > > > > > > INSTALL = ../u:/unixos2/bin/install.exe > > > > > > Having looked into it a little deeper... The above setting only exists > > within Makefiles in subdirectories of RECODE. The value in Makefile in the > > parent directory is fine. So, whatever is adding the '../' is at fault. > > I guess that would be something in the configure script... > > No, the fault is not the "../", but the expansion of $(INSTALL) or alike > to u:/unixos2/bin/install.exe. In this instance I think that $(INSTALL) is derived from CONFIG.SITE where I have:- INSTALL=$BLD_HOME/bin/install.exe > I am sure that there is a shell script > "install" There is usually an install-sh which I thought existed as a fallback in case this configure query fails:- checking for a BSD compatible install... u:/unixos2/bin/install.exe > in the top level directory that is there to circumvent > different "install.exe" versions (BSD and SYSV variants) of different > Unixes. I have included INSTALL in CONFIG.SITE because it seemed that some configure script failed to locate INSTALL.EXE which is always available on the path. Are you suggesting that I remove the setting from CONFIG.SITE? > Holger > > -- > Please update your tables to my new e-mail address: > holger.veit$ais.fhg.de (replace the '$' with ' at ' -- spam-protection) -- John **= Email 10 ==========================** Date: Thu, 27 Feb 2003 15:46:45 +0100 From: Holger Veit Subject: Re: u:/bin/sh: ../u:/unixos2/bin/install.exe: not found On Wed, Feb 26, 2003 at 09:14:18PM +0100, Andreas Buening wrote: > Holger Veit wrote: > > > > On Wed, Feb 26, 2003 at 10:24:25AM +0000, John Poltorak wrote: > > > > > > Why does this sort of thing happen:- > > > > > > u:/bin/sh: ../u:/unixos2/bin/install.exe: not found > > [snip] > > > It is a problem of the "full pathname" which is set in > > argv[0] by EMX. > > Could you be a bit more specific, please? Must correct myself: often the culprit is infact EMX's argv[0] expansion which attempts to return a DOS style pathname for a program name, but here it looks as if the algorithm to locate a program is broken in either the shell or the make program. Apparently the following happens: There is a reference to "../install" in the makefile which often happens with software which brings its own install script (usually, this is called install.sh, but here it looks like the .sh extension is missing - that's perfectly okay). The makefile was called by a Bourne shell, with SHELL=u:/bin/sh.exe set (either explicitly or hardcoded into make, or with a SHELL= in Makefile). Now make wants to execute a "../install" something which may be either a script or an .exe executable. Now the algorithm to locate that file and interpret it is somewhat broken in either the shell or the make: it seems to try to expand the name "install" by adding either the UNIXOS2 prefix (which I think is set to "u:/unixos2/bin") or a PATH component (implying that the PATH contains u:/unixos2/bin) to the basename of the program. This looks as if the expansion algorithm is passed the name of the program alone, rather than the path (i.e. "../install") accumulated so far - it sees the task: "expand 'install'" and returns "u:/unixos2/bin/install.exe" which is certainly installed in a decent UnixOS2 system), rather than "expand '../install'" - the "../" is prepended later, and the shell gets of course confused. I suggest checking the expansion mechanism in the make in use. Holger -- Please update your tables to my new e-mail address: holger.veit$ais.fhg.de (replace the '$' with ' at ' -- spam-protection) **= Email 11 ==========================** Date: Thu, 27 Feb 2003 15:49:56 +0100 From: Holger Veit Subject: Re: u:/bin/sh: ../u:/unixos2/bin/install.exe: not found On Thu, Feb 27, 2003 at 12:56:22PM +0100, Stefan Neis wrote: > On Thu, 27 Feb 2003, John Poltorak wrote: > > > What I'd like to know is why this command is invoked with some apps, > > whilst others run install.exe without any problem by invoking it directly > > rather than through /bin/sh. > > > > I guess it must be something in the Makefile.... > > Some makefiles probably explicitly set SHELL=/bin/sh somewhere and others > don't ... In such a case, you can usually defeat this by passing a SHELL= in the commandline, like in make SHELL= all The imake generated Makefiles have the misfeature of having a hardcoded SHELL=/bin/sh in it, for instance. Holger -- Please update your tables to my new e-mail address: holger.veit$ais.fhg.de (replace the '$' with ' at ' -- spam-protection) **= Email 12 ==========================** Date: Thu, 27 Feb 2003 15:52:57 +0100 From: Holger Veit Subject: Re: u:/bin/sh: ../u:/unixos2/bin/install.exe: not found On Thu, Feb 27, 2003 at 12:38:36PM +0000, John Poltorak wrote: > On Thu, Feb 27, 2003 at 12:22:27PM +0000, John Poltorak wrote: > > On Thu, Feb 27, 2003 at 12:56:22PM +0100, Stefan Neis wrote: > > > On Thu, 27 Feb 2003, John Poltorak wrote: > > > > > > > What I'd like to know is why this command is invoked with some apps, > > > > whilst others run install.exe without any problem by invoking it directly > > > > rather than through /bin/sh. > > > > > > > > I guess it must be something in the Makefile.... > > > > > > Some makefiles probably explicitly set SHELL=/bin/sh somewhere and others > > > don't ... > > > > I don't think that could be the reason. I've just looked at two Makefiles > > and both set SHELL to u:/bin/sh, but they set INSTALL differently. > > > > One (RECODE) set it thus:- > > > > INSTALL = ../u:/unixos2/bin/install.exe > > > Having looked into it a little deeper... The above setting only exists > within Makefiles in subdirectories of RECODE. The value in Makefile in the > parent directory is fine. So, whatever is adding the '../' is at fault. > I guess that would be something in the configure script... No, the fault is not the "../", but the expansion of $(INSTALL) or alike to u:/unixos2/bin/install.exe. I am sure that there is a shell script "install" in the top level directory that is there to circumvent different "install.exe" versions (BSD and SYSV variants) of different Unixes. Holger -- Please update your tables to my new e-mail address: holger.veit$ais.fhg.de (replace the '$' with ' at ' -- spam-protection) **= Email 13 ==========================** Date: Thu, 27 Feb 2003 16:39:31 +0000 From: John Poltorak Subject: Re: u:/bin/sh: ../u:/unixos2/bin/install.exe: not found On Thu, Feb 27, 2003 at 05:16:29PM +0100, Stefan Neis wrote: > On Thu, 27 Feb 2003, John Poltorak wrote: > > > > One (RECODE) set it thus:- > > > > > > INSTALL = ../u:/unixos2/bin/install.exe > > > > > > Having looked into it a little deeper... The above setting only exists > > within Makefiles in subdirectories of RECODE. The value in Makefile in the > > parent directory is fine. > > Whatever is generating the Makefiles in the subdirectories (probably > configure) apparently tries to be clever and tries to determine, whether > INSTALL is described by an abolute or relative path. If it is called via > a relative path, there obviously is a need to prepend "../" if you're > calling $INSTALL from one directory level lower than the main directory. > Now "u:/..." apparently doesn't start with "/", so all the Unix- (Linux-) > centric scripts will detect it as relative path and prepend the "../". Yes, that's exactly what seems to be happening. I changed the value of $INSTALL to remove the drive letter and it worked OK. > Check configure(.in) in for something like > case (...) > /*) #Something not changing install > ;; > *) INSTALL= ../$INSTALL > ;; > esac Is this it:- ? # Adjust a relative srcdir, top_srcdir, and INSTALL for subdirectories. # Remove last slash and all that follows it. Not all systems have dirname. ac_dir=`echo $ac_file|sed 's%/[^/][^/]*$%%'` if test "$ac_dir" != "$ac_file" && test "$ac_dir" != .; then # The file is in a subdirectory. test ! -d "$ac_dir" && mkdir "$ac_dir" ac_dir_suffix="/`echo $ac_dir|sed 's%^\./%%'`" # A "../" for each directory in $ac_dir_suffix. ac_dots=`echo $ac_dir_suffix|sed 's%/[^/]*%../%g'` else ac_dir_suffix= ac_dots= fi case "$ac_given_INSTALL" in [/$]*) INSTALL="$ac_given_INSTALL" ;; *) INSTALL="$ac_dots$ac_given_INSTALL" ;; esac > and add a case for "?:*" which doesn't change install either ... Hmm... I'm not very comfotyable with these weird shell script constructs... > Regards, > Stefan > P.S.: If you're really lucky, that "bug" might be hidden in some m4 > macro collection for autoconf: Hard to find, but once it's > fixed, it helps for more than one package. Sounds like a job for our resident Autoconf expert.... Are you listening Andreas? :-)... > -- > Micro$oft is not an answer. It is a question. The answer is 'no'. > -- John **= Email 14 ==========================** Date: Thu, 27 Feb 2003 17:16:29 +0100 (CET) From: Stefan Neis Subject: Re: u:/bin/sh: ../u:/unixos2/bin/install.exe: not found On Thu, 27 Feb 2003, John Poltorak wrote: > > One (RECODE) set it thus:- > > > > INSTALL = ../u:/unixos2/bin/install.exe > > > Having looked into it a little deeper... The above setting only exists > within Makefiles in subdirectories of RECODE. The value in Makefile in the > parent directory is fine. Whatever is generating the Makefiles in the subdirectories (probably configure) apparently tries to be clever and tries to determine, whether INSTALL is described by an abolute or relative path. If it is called via a relative path, there obviously is a need to prepend "../" if you're calling $INSTALL from one directory level lower than the main directory. Now "u:/..." apparently doesn't start with "/", so all the Unix- (Linux-) centric scripts will detect it as relative path and prepend the "../". Check configure(.in) in for something like case (...) /*) #Something not changing install ;; *) INSTALL= ../$INSTALL ;; esac and add a case for "?:*" which doesn't change install either ... Regards, Stefan P.S.: If you're really lucky, that "bug" might be hidden in some m4 macro collection for autoconf: Hard to find, but once it's fixed, it helps for more than one package. But probably it's somewhere in configure.in ... -- Micro$oft is not an answer. It is a question. The answer is 'no'. **= Email 15 ==========================** Date: Thu, 27 Feb 2003 18:08:50 +0100 (CET) From: Stefan Neis Subject: Re: u:/bin/sh: ../u:/unixos2/bin/install.exe: not found On Thu, 27 Feb 2003, John Poltorak wrote: > Yes, that's exactly what seems to be happening. I changed the value of > $INSTALL to remove the drive letter and it worked OK. (snipp) > Is this it:- ? (snipp) > case "$ac_given_INSTALL" in > [/$]*) INSTALL="$ac_given_INSTALL" ;; > *) INSTALL="$ac_dots$ac_given_INSTALL" ;; > esac That's part I have been looking for. If you insert ?:*)INSTALL="$ac_given_INSTALL" ;; right before the "*) INSTALL=..." line, it should work. Was that from configure? Then the corresponding part of configure.in still needs to be identified and fixed accordingly, and with the fixed configure.in, you could submit a patch/bug report ... Regards, Stefan -- Micro$oft is not an answer. It is a question. The answer is 'no'. **= Email 16 ==========================** Date: Thu, 27 Feb 2003 19:58:38 +0000 From: John Poltorak Subject: TFTPD I'm trying to boot Linux remotely using something called PXELINUX and I need a TFTP server which supports 'tsize'. Apparently IBM's program doesn't. There is some ported app on Hobbes which claims it does support the required option, but the only docs are the source code and I have no idea how it is supposed to work... It doesn't seem to transfer the requested file, but I can't tell whether the program is broken or if I just haven't started it properly... Is anyone familiar with TFTPD and the 'tsize' option? TFTP-HPA has been recommended as a suitable server. I'm wondering if there is any chance of being able to build it on OS/2... -- John **= Email 17 ==========================** Date: Thu, 27 Feb 2003 20:15:00 +0000 From: John Poltorak Subject: Re: TFTPD On Thu, Feb 27, 2003 at 12:11:51PM -0800, James E. Burke Jr. wrote: > I have an IBM version of TFTP Server that juns under java. > I don't recall where I found it, but it's small and I'd be glad to > email it to you. Do you know if if supports 'tsize' ? > >I'm trying to boot Linux remotely using something called PXELINUX and I > >need a TFTP server which supports 'tsize'. > > > >Apparently IBM's program doesn't. > > > >There is some ported app on Hobbes which claims it does support the > >required option, but the only docs are the source code and I have no idea > >how it is supposed to work... It doesn't seem to transfer the requested > >file, but I can't tell whether the program is broken or if I just haven't > >started it properly... > > > > > >Is anyone familiar with TFTPD and the 'tsize' option? > > > >TFTP-HPA has been recommended as a suitable server. I'm wondering if there > >is any chance of being able to build it on OS/2... -- John **= Email 18 ==========================** Date: Thu, 27 Feb 2003 21:14:54 +0000 From: John Poltorak Subject: Re: TFTPD On Thu, Feb 27, 2003 at 12:31:02PM -0800, James E. Burke Jr. wrote: > From the FAQ: > > What is the maximum file size that I can send or receive? > It depends on your client and the server. The TFTP protocol itself uses a > counter which overflows at 32 megabytes. Most clients and servers can't > handle this condition. This TFTP server, however, handles this condition; so > the limitation is based on the filesystem of the server platform. If it doesn't specifically mention 'tsize' I suppose it won't support it. -- John