[xcvb-devel] run-program/process-output-stream

[Peter Keller]

On Thu, Apr 14, 2011 at 11:31:08AM -0400, Faré wrote:
> > Ah, I was just curious, because in perl, this code:
> >
> > @foo = `cat file`;
> >
> > (which is similar in concept to run-program/process-output-lines with the
> > 'slurp-stream-lines output processor) preserves the newline for each line.
> >
> I am aware of that. I wanted some small code use trivial Lisp functionality,
> so I use read-line that behaves like this.

Ok. I figured as much. The behavior really isn't that surprising from a 
lisp-point of view.

> > I'm not advocating change, but I was surprised by the newline difference
> > between the two stream processors.
> >
> > Also, would you prefer that I added docstrings for how to use these
> > functions? Or just commented above them their use/edge cases and whatnot?
> >
> This indeed deserves to be documented, in a comment if not in a
> docstring. I have no preference.

Ok. I'll do whatever feels right.

> As I realize it has to deal with portability, I'm considering having
> master either depend on driver, or be merged into driver so that it
> remains a single file. What do you think?

IMHO, I personally would make a subdirectory called xcvb/vendor and break
up both driver.lisp and master.lisp into individual files representing
their little areas.

So:
xcvb/vendor/run-program.lisp [holds run-program/*, slurp-*, other I/O stuff]
xcvb/vendor/environment.lisp [holds getenv, setenv, do-find-symbol, ]
xcvb/vendor/debugging.lisp [hold debugging, with-profiling, etc]
xcvb/vendor/strings-and-escapes.lisp [escape-windows-command, escape-token, etc]
xcvb/vendor/specials.lisp [all special variables]

Then each portability thing can be thought about and abstracted properly
without being cluttered.

> > BTW, I got hu.dwim.stefil working (and the required externals installed in
> > the same manner as the others) and have started writing a basic unit-test
> > suite for run-program/*. I need to figure out how to test for signaled
> > conditions and other things too, but I'm making progress.
> >
> Excellent. Note that under windows, things are subtly different. Sigh.

Yeah. In dealing with the newline issue, I did this:

;; add a "newline" to a string
(defmacro nl (str) `(format nil "~A~%" ,str))

And then here the skeleton of how I'd use it:

Suppose there is a file containing the single string 'test\n':

;; a basic test, minus the deftest stuff.
(let ((the-string <read-file-into-string-with-slurp-stream-string>))
  (is (string= the-string (nl "test")))

Because then if a lisp implementation uses \n\r versus \n or some other
horrible thing, it should "just work" in the string= comparison.

Am I doing the correct thing in the above?

Also, is #+unix and #+win32 available as conditional compilation features for
all implementations we'd like to support?

> Having to deal with PATHs under Windows is the promise of HELL.

Maybe you can lift this interface:

http://perldoc.perl.org/File/Spec.html

It would be verbose, but you already have a virtual path representation
anyway so maybe it wouldn't be so horrible. 

Later,
-pete