I can live with current situation, or apply this patch on my
local machine.
> ideally we would do all file access via system interfaces
> avoiding Lisp functions.
What's your opinion on using a lisp library, like cl-fad?
http://weitz.de/cl-fad/
--
You received this message because you are subs
oldk1331 wrote:
>
> > '~' is a shell convention. Our file access functions should
> > not prevent accessing file or directiory named '~'.
> > Nor should they require some strange quoting (which is
> > the case with shell).
>
> That's an odd choice. I think '~' is part of POSIX standard?
Well,
> '~' is a shell convention. Our file access functions should
> not prevent accessing file or directiory named '~'.
> Nor should they require some strange quoting (which is
> the case with shell).
That's an odd choice. I think '~' is part of POSIX standard?
Yes, in IO part, lisp and unix don't g
I always wondered whether it's a specific SBCL issue. In Cygwin (clisp)
there's no problem. On the other hand )lisp (load "~/dir/file") also works
with SBCL compiled fricas.
BTW )read $HOME/... fails in both.
On 10 October 2016 at 04:51, oldk1331 wrote:
> SBCL specific bug, I think?
>
> "~/tmp/
oldk1331 wrote:
> SBCL specific bug, I think?
>
> "~/tmp/1.input" exists, )read just don't understand "~".
>
> (1) -> )read ~/tmp/1.input
>
>The file ~/tmp/1.input is needed but does not exist.
>
> "probe-file" just works in SBCL, while "sbcl-file-kind"
> doesn't recgnoize "~". Maybe more
SBCL specific bug, I think?
"~/tmp/1.input" exists, )read just don't understand "~".
(1) -> )read ~/tmp/1.input
The file ~/tmp/1.input is needed but does not exist.
"probe-file" just works in SBCL, while "sbcl-file-kind"
doesn't recgnoize "~". Maybe more parts can be changed.
The patch is:
