#364 cannot create pathnames with :wild-inferiors

lisp error
closed-fixed
clisp (524)
5
2006-09-10
2006-09-09
No

Pathnames with :wild-inferiors followed by a sub-
directory cannot be created. The following error
arises:
"*** - PARSE-NAMESTRING: cannot access values of an
array of element type NIL"

#P"/**/subdir/" => error
(make-pathname :directory '(:absolute :wild-
inferiors "subdir")) => error

However, no error when
* the device or a filename is provided:
#P"C:/**/subdir/" => #P"C:\\**\\subdir\\"
#P"/**/name" => #P"\\**\\name"
* relative pathname is used:
#P"**/subdir//" => #P"**\\subdir\\"
* :wild, rather than :wild-inferiors is used:
#P"/*/subdir/" => #P"\\*\\subdir\\"
* :wild-inferiors is the last directory name
#P"/**/" => #P"\\**\\"

Note - this is not a printing problem since
(progn #P"/**/subdir/" nil) => error

Discussion

  • Aneil Mallavarapu

    Logged In: YES
    user_id=870521

    Version:
    "2.39 (2006-07-16) (built on stnt067 [192.168.0.1])"

    Also tried versions 2.38, 2.37 with same effect.

     
  • Sam Steingold

    Sam Steingold - 2006-09-09

    Logged In: YES
    user_id=5735

    works for me:

    [5]> (make-pathname :directory '(:absolute :wild-inferiors
    "subdir"))
    #P"/**/subdir/"
    [6]> #P"/**/subdir/"
    #P"/**/subdir/"
    [7]> (pathname-directory *)
    (:ABSOLUTE :WILD-INFERIORS "subdir")
    [8]>

     
  • Sam Steingold

    Sam Steingold - 2006-09-09
    • status: open --> pending-works-for-me
     
  • Sam Steingold

    Sam Steingold - 2006-09-09

    Logged In: YES
    user_id=5735

    This bug report is now marked as "pending"/"works for me".
    This means that we think that we cannot reproduce the problem
    and cannot do anything about it.
    Unless you - the reporter - act within 2 weeks
    (e.g., by submitting a self-contained test case),
    the bug will be permanently closed.
    Sorry about the inconvenience -
    we hope your silence means that
    you are no longer observing the problem either.

     
  • Aneil Mallavarapu

    Logged In: YES
    user_id=870521

    I am running the win32 version. Does that make a
    difference?

    What I did (on 3 separate Windows XP SP2 machines):

    1) Got fresh download of
    http://prdownloads.sourceforge.net/clisp/clisp-2.39-
    win32-with-readline-and-gettext.zip?download
    from 2 separate US sites
    Unzipped.

    2) ran CLisp.exe

    3) typed exactly:
    #P"/**/subdir/"
    which results in error.

    Here is the "screenshot":
    i i i i i i i ooooo o ooooooo ooooo
    ooooo
    I I I I I I I 8 8 8 8 8 o
    8 8
    I \ `+' / I 8 8 8 8
    8 8
    \ `-+-' / 8 8 8 ooooo
    8oooo
    `-__|__-' 8 8 8 8 8
    | 8 o 8 8 o 8 8
    ------+------ ooooo 8oooooo ooo8ooo ooooo 8

    Copyright (c) Bruno Haible, Michael Stoll 1992, 1993
    Copyright (c) Bruno Haible, Marcus Daniels 1994-1997
    Copyright (c) Bruno Haible, Pierpaolo Bernardi, Sam
    Steingold 1998
    Copyright (c) Bruno Haible, Sam Steingold 1999-2000
    Copyright (c) Sam Steingold, Bruno Haible 2001-2006

    [1]> #P"/**/subdir/"

    *** - PARSE-NAMESTRING: cannot access values of an array of
    element type NIL
    The following restarts are available:
    ABORT :R1 ABORT
    Break 1 [2]> (lisp-implementation-version)
    "2.39 (2006-07-16) (built on stnt067 [192.168.0.1])"
    Break 1 [2]>

     
  • Aneil Mallavarapu

    • status: pending-works-for-me --> open-works-for-me
     
  • yyk

    yyk - 2006-09-09

    Logged In: YES
    user_id=1264398

    I confirm this bug on win32.
    How debug it?

    --
    WBR, Yaroslav Kavenchuk.

     
  • yyk

    yyk - 2006-09-09

    Logged In: YES
    user_id=1264398

    Excuse me.
    What is the #P"/" on win32?

    $ full/lisp.exe -M full/lispinit.mem -q -norc
    [1]> #P"/**/full/"

    *** - PARSE-NAMESTRING: cannot access values of an array of
    element type NIL
    The following restarts are available:
    ABORT :R1 ABORT
    Break 1 [2]> :a
    [3]> #P"./**/full/"
    #P"**\\full\\"
    [4]>

    Excuse me once more.

    --
    WBR, Yaroslav Kavenchuk.

     
  • Sam Steingold

    Sam Steingold - 2006-09-09

    Logged In: YES
    user_id=5735

    please run under gdb:
    (gdb) run
    > #P"/**/full/"
    (gdb) where
    and then examine (with xout/zout) variables in suspicious
    frames.

     
  • Sam Steingold

    Sam Steingold - 2006-09-10
    • milestone: --> lisp error
    • assigned_to: haible --> sds
    • status: open-works-for-me --> closed-fixed
     
  • Sam Steingold

    Sam Steingold - 2006-09-10

    Logged In: YES
    user_id=5735

    thank you for your bug report.
    the bug has been fixed in the CVS tree.
    you can either wait for the next release (recommended)
    or check out the current CVS tree (see http://clisp.cons.org\)
    and build CLISP from the sources (be advised that between
    releases the CVS tree is very unstable and may not even build
    on your platform).

     

Log in to post a comment.