Guillermo Polito wrote
I try not to depend on projects using OSProcess in that case.
That is not exactly a robust solution! What is the only project providing the functionality you need depends on OSP?! Guillermo Polito wrote
I understand that the incompatibilities bother, but putting all the fault in OSSubprocess and not in OSProcess seems not fair :)
Ha ha, well OSProcess was born in 2005, and then OSSP appeared reusing some of its functionality just recently, so I'd say it's fair indeed! Guillermo Polito wrote
Maybe both should be modified to be compatible?
Maybe. I don't really understand the source of the incompatibility well enough. Guillermo Polito wrote
I found OSProcess API particularly bad. It's never clear to me whether to use OSProcess, PipeableSomething or CommandWhatever (I don't even remember the names of the things that **do work** and I have to look them every time).
The things you're describing are not accidental complexity, but the fact that OSP (and its companion CommandShell) actually have a far wider feature set than just simple commands. CommandShell makes many shell-like things possible in-image, but one doesn't have to use or even know anything about all that to do simple things. That said, every time I did into CS and see all the things that are possible I am amazed. Guillermo Polito wrote
Most people only want to do output := OSProcess executeCommand: 'ls'. Blocking. Recovering stdout. And that's all.
(PipeableOSProcess command: 'ls') output That doesn't seem horribly complex to do in OSP ;) Guillermo Polito wrote
Well from a technical point of view, if you want to choose from one or another today I'd sayâ¦
Ah, interesting and informative. Thank you. ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html