On 2/24/13 Feb 24 -7:05 PM, Faré wrote: > On Sun, Feb 24, 2013 at 7:14 PM, Robert Goldman <[email protected]> wrote: >>>> TEST ABORTED: Subprocess run with command "/bin/ln -sf >>>> /Users/rpg/lisp/asdf/test/test-multiple.asd >>>> /Users/rpg/lisp/asdf/build/test-multiple-too.asd 2>&1" exited with error >>>> code 1 >>>> >>>> No backtrace for this. >> >> I believe the problem is that EXT:SYSTEM on ECL runs whatever shell is >> the value of SHELL, but your test code is all written for bash, without >> checking for it. >> >> I use the T shell. >> >> Probably a good thing that I am testing with this unusual configuration! >> >> I suppose the test code should force SHELL to be bash. I don't know if >> there's a portable way to do this. ASDF used to invoke /bin/sh, in >> RUN-SHELL-COMMAND, IIRC. >> > It is possible that there is a bug in asdf/driver:run-program, > or maybe one in ECL itself. Can you run again while tracing as follows? > (trace asdf/driver:run-program ext:run-program ext:shell) > > I think the test-multiple might pass if you the /bin/ in /bin/ln. > > Is the "T shell" the same thing as tcsh? Let me try it... > Indeed, I can reproduce the failure with > SHELL=tcsh make t l=ecl t='test-run-program.script > even though this works: > SHELL=tcsh make t l=ccl t='test-run-program.script > That's because somehow ECL, to get the exit value of a process, > reverts to a more primitive call to system, and then > relies on "exec > tmpfile ; command" for redirection, > independently from the content of command. > It looks like this is not portable to tcsh; > and probably not to Windows, either. > I don't know how to solve this problem portably > or to automatically detect a workaround. > > Maybe the test script runner should just export SHELL=/bin/sh ?
That sounds right for the short term. I don't claim to have fully grokked ASDF:RUN-PROGRAM yet. Would it be reasonable to modify it so that when :force-shell is T (a) it prefers /bin/sh to alternatives, or CMD.EXE on windows? and (b) it allows the user to override and request her shell to be used? The reason I suggest this is that it would provide a consistent way to encapsulate the behavior we see from ECL. We default to a standard shell for the maximum in portability, but we allow the programmer to demand his shell under some circumstances? I have given this exactly 2.4 seconds of thought, so this might be A Very Stupid Idea. I was just looking for a portable way to keep ecl's behavior and other systems behaviors consistent when viewed through ASDF:RUN-PROGRAM. > > >>>> * ABCL 1.1.0.2 failed test-encodings: [...] >>> Weird. Looks like the UTF-8-encoded characters were read as MacRoman. >>> Within which sub-test does that occur? A bit more context above would help. >> >> This is the one that failed: >> >> (with-encoding-test (explicit-u8 :utf-8) >> (def-test-system :test-encoding-explicit-u8 >> :components ((:file "lambda" :encoding :utf-8)))) >> >> Note that to make this work, I added a dynamic variable that bound >> asdf-test::*test-name* and made the assert-compare-helper incorporate >> that name in its output. >> >> The dynamic variable was a little yucky, but otherwise I would have had >> to push the name (as an optional) through the arglist of all of the >> comparison macros.... >> >> This might be useful for debugging, but the implementation is super nasty. >> > I'm not sure what you changed to "make it work". > If explicit request for utf-8 encoding doesn't work, > something is probably broken in either asdf and/or abcl. Sorry -- "make it work" just meant "make it so that I could determine which test failed," not "make the encoding behave correctly." best, r _______________________________________________ asdf-devel mailing list [email protected] http://lists.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
