#86 path for tags files should be resolved

release
closed-accepted
Alexander Mai
Program (402)
7
2001-11-20
2001-11-08
No

If a specified tags file is a symbolic link then the
definition cant' be found if the tag file uses
relative paths for the definition source (that's quite
usual) and the real tag file the symlink points to is
not in the same directory like the symlink.

The patch appended fixes this by simply resolving
the tags files path just before loading it. For the
user nothing (exept more tags will be found ;-) nothing
changes - especially the original logical tags file
path (i.e. the symlink) remains visible in the menus.

Limitations:

I don't know if resolvepath() is defined on all
systems we use.

Discussion

  • cvs diff -c tags.c (tags.c revision 1.22)

     
    Attachments
  • Alexander Mai
    Alexander Mai
    2001-11-08

    Logged In: YES
    user_id=15180

    No.
    I have no idea what resolvepath() is, at least it doesn't
    look being part of any programming standard in question.
    Where did you dig out this one?

     
  • Alexander Mai
    Alexander Mai
    2001-11-08

    • labels: --> Program
     
  • Logged In: YES
    user_id=81393

    On Sun (solaris 5.7):
    It's defined in /usr/include/unistd.h
    (copyright notes 1988 AT&T,
    1996-1998 by Sun Microsystems, Inc.)
    and the manual page is in
    /usr/man/sman2/resolvepath.2
    and its contained in /usr/lib/libc.*

    IIRC it's there in linux (Suse 7.1) too.

    I couldn't find it in SunOS 4.1.3.

     
  • Logged In: YES
    user_id=81393

    ok, resolvepath seems to exist only on solaris.
    (it resolves all symbolic links in the path name path
    into a resulting path name free of symbolic links and
    returns an absolute pathname. readlink only returns
    the simple link).

    I' ll rewrite the patch soon using readlink (this
    will result most probably in an additional function
    ResolvePath in util/fileUtils.c)

     
  • Alexander Mai
    Alexander Mai
    2001-11-09

    • milestone: --> release
    • status: open --> open-rejected
     
  • cvs diff -u (tags.c 1.22, fileUtils.c 1.14, fileUtils.h 1.5)

     
  • Logged In: YES
    user_id=81393

    Thanks for the link below...
    Now here is the rewritten patch using mainly readlink
    and functions already existing in fileUtils.c.
    first tests were passed sucessfully.

     
  • Alexander Mai
    Alexander Mai
    2001-11-12

    Logged In: YES
    user_id=15180

    Ok, now we still have to take care of systems that don't
    have links or readlink(2) or both!?
    Perhaps
    int ResolvePath()
    #ifdef NO_READLINK
    // do fallback, just copy path, etc.
    #else
    ...
    #endif
    That #define would have to be documented in Makefile.generic.

    I'll commit something like this in a minute.

     
  • Alexander Mai
    Alexander Mai
    2001-11-12

    • assigned_to: nobody --> amai
    • status: open-rejected --> open-accepted
     
  • Alexander Mai
    Alexander Mai
    2001-11-13

    • priority: 5 --> 7
     
  • Alexander Mai
    Alexander Mai
    2001-11-13

    Logged In: YES
    user_id=15180

    Someone feel liks help in testing this one?
    Also we need to check which systems require the #define:
    VMS perhaps?
    Raising the priority because it's likely to break
    compilation until all Makefiles which need this #define have
    been adjusted.

     
  • Logged In: YES
    user_id=81393

    Perhaps a way to relax things is to additionally test for
    the macro MAXSYMLINKS (I suppose if a OS has readlink it
    also should have MAXSYMLINKS and vice versa)

    int ResolvePath()
    #if defined(NO_READLINK) || !defined(MAXSYMLINKS)
    // do fallback, just copy path, etc.
    #else
    ...
    #endif

    So if in a os not having readlink (which should result
    in not having MAXSYMLINKS defined) the -DNO_READLINK
    in the makefile is missing: compilation still should not be
    broken. Perhaps (for that we should know <unistd.h> and
    <sys/param.h> of all systems we compile NEdit on) even
    testing for MAXSYMLINKS would be sufficient.

     
  • Alexander Mai
    Alexander Mai
    2001-11-13

    Logged In: YES
    user_id=15180

    Well, sounds like a reasonable idea, but OTOH it will just
    make it more difficult for us to analyze things when reports
    about unsuccessful builds will come in.
    I'm sure we can deal with this, the majority of all
    NEdit-platforms is un*x-like nevertheless.

     
  • Alexander Mai
    Alexander Mai
    2001-11-20

    • status: open-accepted --> closed-accepted
     
  • Alexander Mai
    Alexander Mai
    2001-11-20

    Logged In: YES
    user_id=15180

    Ok, seems to be fixed?!