[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: scsh on GNU/Hurd
From: |
Martin Gasbichler |
Subject: |
Re: scsh on GNU/Hurd |
Date: |
Fri, 24 May 2002 10:05:25 +0200 |
User-agent: |
Gnus/5.090005 (Oort Gnus v0.05) XEmacs/21.5 (bamboo, i386-unknown-freebsd4.3) |
>>>>> "Niels" == Niels Möller <nisse@lysator.liu.se> writes:
Niels> Hi,
Niels> I've compiled scsh-0.5.3 on a current Hurd machine, which required
Why didn't you try the current version (0.6.2) of scsh? It's avaiable
from http://www.scsh.net/download.html and contains a lot more
features than 0.5.3.
Niels> some minor hacking. config.guess output on this machine was
Niels> "i386-unknown-gnu0.2". The steps needed were:
Niels> 1. I added
Niels> *-*-gnu* )
Niels> dir=gnu
Niels> SCSH_ELF
Niels> ;;
Niels> at about line 295 in configure.in, just below the
Niels> "*-*-linux* )"-clause.
Niels> 2. I copied the scsh/linux directory to a new directory scsh/gnu.
Niels> 3. In syscalls1.c, I added the lines
Niels> /* MAXPATHLEN is not defined on the Hurd. */
Niels> /* FIXME: Do this properly, and get rid of the static memory as well
*/
Niels> #ifndef MAXPATHLEN
Niels> #define MAXPATHLEN 500
Niels> #endif
Niels> just before the definiton of scm_readlink,
Niels> /* Read the symlink into static memory. Return NULL on error. */
Niels> static char linkpath[MAXPATHLEN+1]; /* Maybe unaligned. Not
reentrant. */
Niels> char const *scm_readlink(const char *path)
Niels> {
Niels> int retval = readlink(path, linkpath, MAXPATHLEN);
Niels> return (char const *)
Niels> ((retval == -1) ? NULL : ( linkpath[retval] = '\0', linkpath
));
Niels> }
Niels> This is an ugly hack, but I haven't figured out how to fix
Niels> scm_readlink properly.
The code for scm_readlink looks slightly differernt in 0.6.2. Freeing
the buffer is no problem there. Here is a patch that does essentially
the same as the GLib C example quoted by Marcus Brinkmann but has no
memory leaks:
Index: syscalls1.c
===================================================================
RCS file: /cvsroot/scsh/scsh-0.6/scsh/syscalls1.c,v
retrieving revision 1.31
diff -u -c -r1.31 syscalls1.c
*** syscalls1.c 11 Feb 2002 17:32:20 -0000 1.31
--- syscalls1.c 24 May 2002 08:01:32 -0000
***************
*** 189,195 ****
/* Read the symlink. */
!
s48_value scsh_readlink(s48_value sch_path)
{
char linkpath[MAXPATHLEN+1];
--- 189,195 ----
/* Read the symlink. */
! #ifdef MAXPATHLEN
s48_value scsh_readlink(s48_value sch_path)
{
char linkpath[MAXPATHLEN+1];
***************
*** 202,207 ****
--- 202,238 ----
return s48_enter_string(linkpath);
}
}
+ #else
+ s48_value scsh_readlink(s48_value sch_path)
+ {
+ char *linkpath;
+ int size;
+ int retval;
+ s48_value sch_sym_link_path = S48_UNSPECIFIC;
+
+ for (size = 256;; size *=2){
+
+ linkpath = Malloc(char,size);
+ if (!linkpath)
+ s48_raise_os_error_1(errno, sch_path);
+
+ retval = readlink(s48_extract_string (sch_path), linkpath, size);
+
+ if (retval == -1){
+ free (linkpath);
+ s48_raise_os_error_1(errno, sch_path);
+ }
+
+ if (retval < size){
+ sch_sym_link_path = s48_enter_substring (linkpath, retval);
+ free (linkpath);
+ return sch_sym_link_path;
+ }
+ free (linkpath);
+ }
+ }
+ #endif
+
s48_value scsh_rename(s48_value sch_from, s48_value sch_to)
{
Niels> 3. sigset_t seems to be a plain unsigned int, so I had to redefine the
Niels> macros in scsh/gnu/sigset.h, as follows:
Niels> /* On gnu, it seems a sigset_t is just an unsigned int. */
Niels> #define make_sigset(maskp, hi, lo) \
Niels> (*(maskp) = (unsigned long int) ((hi) << 24) | (lo))
Niels> #define split_sigset(mask, hip, lop)\
Niels> ((*(hip) = ((mask) >> 24) & 0xff),\
Niels> (*(lop) = ((mask) & 0xffffff)))
These hacks are gone in the 0.6 series of scsh.
Niels> After these steps, both make and make check succeeded.
There is another small test suite, which can be invoked by
./go -lm scsh/test/test-packages.scm -o test-all -c "(test-all)"
in the top-level directory of scsh-0.6.2.
I suspect some more adjustments are required in the scsh/gnu/
directory, but I don't know, how releated Hurd and Linux
are. doc/porting.txt provides some (maybe out-dated) information on
this topic.
Thanks for the report!
--
Martin