Closed matthewleon closed 7 years ago
The whole reason for expanding the globs inside the compiler rather than on the command line was to get around cases where the expanded command was too long for shells to accept, so this will most likely run into the same issue.
What about using some more bash magic:
purs compile `psc-package sources | sed -e "s/\(.*\)/'\1'/" | paste -sd " "`
Disclaimer: I couldn't test this on psc-package, but it seemed to run fine on ls -1
@kRITZCREEK I understand your point. Makes sense.
That said, requiring users to do "bash magic" like what you posted is pretty unfriendly. Can we do better somehow?
I guess in the end the solution might just be the development of user-facing tools that sit in front of psc-package
, or between psc-package
and other tools.
Yeah I think that might have to be it, sadly.
My apologies for having a few false starts on this, but it's been a bit of a tricky issue.
Currently,
psc-package sources
outputs a list of globs, which can lead to some unintuitive behavior in some shells when used as a parameter topurs
commands. This certainly got me, and though my shell-fu is admittedly a bit weak, I imagine that others will find this to be hard to debug as well.I feel like something should be done to deal with this. Perhaps the default behavior of
psc-package sources
should be to simply list every individual file among the dependencies, rather than the globs.