On Mon, May 07, 2012 at 10:05:12PM -0700, Sean P. DeNigris wrote: > > David T. Lewis wrote > > > > ProxyPipeline command: '/bin/sleep 10' > > This gives you exactly what you expect to see. > > > > Okay, it worked! However, I'm confused by the string escaping. Because I'm > on a Mac, and only later discovered that meant I'm on Unix, I have lots of > paths with spaces and even [gasp] apostrophes in them (the second makes > Smalltalk strings a lot of fun). One thing that I loved about OSProcess is > that I felt like I had more control over strings (e.g. paths) in commands > because I could construct my paths in Smalltalk and then just double-quote > the final product. > > However, using ProxyPipeline, it seems that CommandShell has layered on its > own escaping rules that are different from Bash's. So, although I can write: > p := PipeableOSProcess command: '/usr/bin/java > -DJENKINS_HOME="/path/with/a > space/and/an/apostrophe/isn''t/fun/Pharo-1.4/.jenkins"...' > > with ProxyPipeline, I apparently have to write: > p2 := ProxyPipeline command: '/usr/bin/java -DJENKINS_HOME=/path/with/a\ > space/and/an/apostrophe/isn\''t/fun/Pharo-1.4/.jenkins...' > > I.e. "enclose in double-quotes" vs. "escape single-quotes and spaces with > preceding backslash" > > Can I somehow circumvent these extra rules so I don't have to adapt all my > commands? What is their purpose? > > Getting closer and closer to having this work...
Hi Sean, I'm afraid that the simulation of unix shell behavior is far from perfect, and many things that you might expect from a real shell (notably including shell variables and some of the substitution behaviour you are experiencing here) are either missing from CommandShell, or behave differently for various reasons. In this case you are seeing a mashup of Smalltalk string escaping in a unix-like command shell. You are first composing a string in Smalltalk, so the "enclose in double-quotes" rules apply. Then you are (quite reasonably) expected that preceeding-backslash quoting should work in a unix shell, but it does not work here because I never put that into the shell syntax processing. Yes, this is confusing. No, there is no easy workaround or fix. I'm afraid that doing a complete and faithful reproduction of bash would be a fool's errand, just way too much work to be worth the trouble. Adding backslash escaping would not be hard to do but ... well, when it comes to adding features, where do you stop? ;) BTW, I would welcome patches to improve things like this, as long as they are supported with unit tests. Dave
