Passing a POSIX path with Extended ASCI characters to a Shell

34 views
Skip to first unread message

André Tremblay

unread,
Jul 16, 2018, 9:40:27 PM7/16/18
to SuperCard Discussion
Hello, 

When I pass a POSIX path containing Extended ASCI characters, for instance letter “e” with acute accent which is “é”, I am not getting the intended result.

The path being converted with HFStoPOSIX() XCFN and looks correct with ScriptTracer. 

For instance:

put shell(merge("mv -f `[[OriginPosixPath]]` `[[NewNamePosixPath]]`")) into ShellResult


My first question:


Should I do an additional conversion before passing such a character? Would it be the same procedure for Unicode characters?


Second question: 


How do I get a result into the ShellResult variable? It is returning EMPTY at the moment. 


Thank you for your help


André Tremblay

PhotoGraphex






codegreen

unread,
Jul 17, 2018, 2:49:03 AM7/17/18
to SuperCard Discussion
Try this:

put unixTask(empty, "/bin/bash", "-c", merge("mv -f `[[OriginPosixPath]]` `[[NewNamePosixPath]]`"))


-Mark

André Tremblay

unread,
Jul 17, 2018, 9:52:00 AM7/17/18
to SuperCard Discussion
Hello Mark,

put unixTask(empty, "/bin/bash", "-c", merge("mv -f `[[OriginPosixPath]]` `[[NewNamePosixPath]]`"))


That does return the expected behavior from a path name or to a path name containing ASCI extended characters!

Thank you very much!

I have to read the documentation to understand better the differences between “Shell” and “UnixTask” functions. 

My second question, maybe it is not relevant in this context, but, how do I get a result from this function?

Regards

André Tremblay
PhotoGraphex

codegreen

unread,
Jul 17, 2018, 2:05:42 PM7/17/18
to SuperCard Discussion
On Tuesday, July 17, 2018 at 9:52:00 AM UTC-4, André Tremblay wrote:
My second question, maybe it is not relevant in this context, but, how do I get a result from this function?

Not sure what that question means...

When you run a shell script with unixTask, normally stdout is returned by the function and stderr is put in the result (though of course you can change that in the script with redirection).

Does that help any?

-Mark

codegreen

unread,
Jul 17, 2018, 4:01:18 PM7/17/18
to superca...@googlegroups.com
(On Tuesday, July 17, 2018 at 9:52:00 AM UTC-4, André Tremblay wrote:
I have to read the documentation to understand better the differences between “Shell” and “UnixTask” functions. 

FYI under the hood shell uses BSD's popen while unixTask uses Cocoa's NSTask.

One important consequence of this is that the command string you pass is flat text in the first case, but an opaque (internally Unicode-based) Cocoa object in the second.

Another is that while it's technically possible to feed data to popen's stdin, it requires a non-obvious trick the folks at Apple DTS who helped me set that up apparently hadn't learned yet (back in 2001) and has a hard (but variable) input length limit that you can't really determine accurately in advance (so in effect it's possible, but not practical). With NSTask though, while it also requires some undocumented space voodoo you can basically pipe unlimited amounts of data to a shell script via stdin (instead of having to somehow embed it directly into the command).

In practice that meant it wasn't feasible to perform any sort of automatic encoding conversion on the input to shell (because it might contain anything) but in unixTask (where any stdin arrives via a separate dedicated parameter) I could assume that what was in the argument parameter(s) was pure text and safely transcode it from MacRoman to UTF.

Note that both forms still do automatic CR<->LF swapping on the input and output unless you add the raw option (which comes last in shell, but first in unixTask). And with raw there's usually a trailing linefeed in the output (which you'll likely want to remove manually).

Another important difference is that in unixTask you can communicate back and forth with SC from the script using scdo and scget (which are special dedicated command-line tools included within the SC bundle that interact with the interpreter via AppleEvents) so your shell scripts no longer need to be black boxes.

And of course (assuming you're not somehow relying on shell built-in commands or macros) you can typically execute a low-overhead BSD command-line tool (e.g., date) much faster if you call it directly using unixTask (i.e., NSTask) than via shell (i.e., popen) because SC doesn't have to instantiate a whole unix shell just to call it.

HTH,
-Mark

André Tremblay

unread,
Jul 23, 2018, 10:14:33 PM7/23/18
to SuperCard Discussion

FYI under the hood shell uses BSD's popen while unixTask uses Cocoa's NSTask.


Thank you Mark for expanding the scope of my knowledge. I have started to do some reading around those topic. 

My best regards

André Tremblay
PhotoGraphex

 
Reply all
Reply to author
Forward
0 new messages