Can you show an example of UIOP failing? Works for me—the chdir is the protection form of an unwind-protect.
(require :asdf) (in-package :uiop) (progn (with-output-file (s "/tmp/foo" :if-exists :supersede :if-does-not-exist :create) (write `(1 bar ,(+ 2 2)) :stream s)) (with-current-directory ("/tmp/") (safe-read-file-form "foo")))
(1 COMMON-LISP::BAR 4)
(with-current-directory ("/tmp") (uiop:run-program (list "echo" "program") :output :string))
"program " NIL 0
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org “Anarchy is order, government is civil war.” — Anselme Bellegarrigue
On Tue, Aug 20, 2024 at 4:27 AM Robert Goldman rpgoldman@sift.info wrote:
I haven't checked carefully, but I think you need to work around this with something like
(let (result) (uiop:with-current-directory (dir) (setq result (uiop:run-program (list "some" "program") :output :string))) result)
The problem with changing this behavior is that it wouldn't be forwards-compatible: if you write code that depends on this change, you would have to condition it on the ASDF release version. So I don't object to making the change, but it's a niche issue and one that could cause headaches when ASDF/UIOP aren't updated. So I'm not going to code it up myself, but I would consider a merge request.
Best, R
On 19 Aug 2024, at 17:01, Kevin Zheng wrote:
Hi asdf developers,
I recently was writing some code with UIOP:CALL-WITH-CURRENT-DIRECTORY and came across something slightly unexpected.
In particular, running CALL-WITH-CURRENT-DIRECTORY or WITH-CURRENT-DIRECTORY forms evaluates to NIL, whereas one may expect that the form evaluates to the return value of THUNK or the macro body, respectively.
In my program, I'm trying to do something like:
(uiop:with-current-directory (dir) (uiop:run-program (list "some" "program") :output :string))
Which doesn't quite do what I want it to do.
I believe this has to do with the definition, which ends in a trailing (chdir dir) form to get out of the directory which unfortunately returns NIL instead of the value from evaluating THUNK.
So my question is: would it be acceptable if a future version of UIOP changes call-with-current-directory to return the value of evaluating THUNK?
Thanks, Kevin