Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[MrBiff]

Sometime in MC29 I think:

https://yabb.jriver.com/interact/index.php?topic=133431.0

the Links feature got the ability to open an external program.  And it works on Windows.  But I can't seem to get anything to happen on macOS.  Is this not functional on this platform?

[bob]

Looks like it's not.
Since Mac uses app bundles it's likely going to need some modification.

[zybex]

What about calling /bin/bash or /usr/bin/open with some args?

[MrBiff]

Those don't either.  I tried.

/usr/bin/open was the first I tried, then tried Calculator.app for a test.  Fail.

[zybex]

The slashes need to be escaped, I think:
//usr//bin//open

Or try the Browse button to point to an .app.
But perhaps the code is just missing, from what Bob said.

[MrBiff]

I can open a shell with //usr//bin//open with Parameters:

//bin//zsh

IF it has no arguments.  As soon as arguments are added to Parameters, it fails:

//bin//zsh -c "echo hello"

[JimH]

Try
man zsh

[MrBiff]

Code: [Select]

$ zsh -c "echo hello"
hello

[zybex]

Won't that command execute the echo and immediately exit zsh? You may see a brief window flashing and then closing immediately, or maybe not even that. Try some command that you can confirm that it did execute. Maybe zsh -i -c "echo hello world".

Also, why not run /bin/zsh directly instead of /usr/bin/open?

[MrBiff]

Sorry, but none of those works.

As soon as arguments are added, nothing runs.  There is no terminal app opening.

No Terminal is opened with calling //bin//bash directly.  Adding -i to the Parameters does not help.

Terminal.app will be opened when //usr//bin//open is used and //bin//zsh or //bin//bash is the Parameters value.  Add more args, nothing happens.

Exec'ing programs on *unixy* systems is so straightforward, there has to be something not coded correctly with the argument (Parameters) processing (which is likely being handled the Windows way).

[zybex]

You may need --args:
https://ss64.com/mac/open.html

Test the open command first on a terminal window to see what works there.

If MC can run the //usr//bin//open, shoudn't it be able to run //bin//bash directly too as it's just another executable? Sorry for dumb questions, I'm not a Mac guy.

Edit: From google on how to run a script (don't forget to escape //slashes):
open -a Terminal ~/test.sh --args -arg1 -arg2 --whatever 123
or
open -a /Applications/Utilities/Terminal.app ~/test.sh --args -arg1 -arg2 --whatever 123

[MrBiff]

From a shell command, this works:

Code: [Select]

open -a textedit
From MC's Links,  this does nothing:

Code: [Select]

Program Paths: //usr//bin//open
Parameters: -a textedit

From the command line, this works and opens test.txt

Code: [Select]

open /System/Applications/TextEdit.app /tmp/test.txt
From MC's Links, this opens TextEdit:

Code: [Select]

Program Paths: //usr//bin//open
Parameters: //System//Applications//TextEdit.app

But this does nothing:

Code: [Select]

Program Paths: //usr//bin//open
Parameters: //System//Applications//TextEdit.app //tmp//test.txt


[zybex]

Right, looks like a bug in argument splitting, or on how they're given to the target process.

[bob]

I just implemented this.
It was kind of a pain in the $$ but it's done the right way.
It will be in the next build.

[zybex]

Thanks Bob
Does it handle quoted args?
arg1 "arg2 with spaces" arg3 ...

[bob]

Thanks Bob
Does it handle quoted args?
arg1 "arg2 with spaces" arg3 ...

Yes but I don't think it handles more than one arg.
From what I can tell the windows one didn't.

[zybex]

This works in windows:

Program: cmd.exe
Args: //k echo "[Filename]" && echo [Artist]

The win32 API CreateProcess() takes a single string with the full command line to execute and splits the args itself - the caller just sends the whole thing. The ShellExecute() takes the executable name plus a second string with all args as well.

[bob]

This works in windows:

Program: cmd.exe
Args: //k echo "[Filename]" && echo [Artist]

The win32 API CreateProcess() takes a single string with the full command line to execute and splits the args itself - the caller just sends the whole thing. The ShellExecute() takes the executable name plus a second string with all args as well.

Yeah, I doubt that will work on Mac as I wrote it. If it doesn't I'll see about splittng the args.

[MrBiff]

Great, thank you very much.

The argument passing and quoting rules for commands executed via cmd.exe were insanely stupid and naive.  One of the rules: a single string argument that has exactly two double quotes, at the beginning and end, gets handled specially.  So it was common to think of these command arguments as a single string.

PowerShell, while a very odd duck, supports handling arbitrary command line arguments via single base64 encoded string.   This eliminates all the impossible-to-handle quoting issues that have been present in the MS command line environment for ~40 years.

The first time I had to write Win32 code, and was gobsmacked when I read that CreateProcess took a string argument (...use quoted strings to indicate where the file name ends and the arguments begin...).  Oye.

[MrBiff]

Yeah, I doubt that will work on Mac as I wrote it. If it doesn't I'll see about splittng the args.

I'll definitively need arguments as individual ARGV items.

[MrBiff]

This isn't working correctly:

Code: [Select]

<Link version="1.2">
<Item Name="Name">PRUNE</Item>
<Item Name="Action">0</Item>
<Item Name="Base URL"/>
<Item Name="Search URL"/>
<Item Name="Type">1</Item>
<Item Name="Program Path">//usr//bin//open</Item>
<Item Name="Program Parameters">//System//Applications//TextEdit.app  //tmp//test.txt</Item>
<Item Name="Filter"/>
</Link>
It just opens a Terminal shell.

That's about all I'm able to get.

[bob]

This isn't working correctly:

Code: [Select]

<Link version="1.2">
<Item Name="Name">PRUNE</Item>
<Item Name="Action">0</Item>
<Item Name="Base URL"/>
<Item Name="Search URL"/>
<Item Name="Type">1</Item>
<Item Name="Program Path">//usr//bin//open</Item>
<Item Name="Program Parameters">//System//Applications//TextEdit.app  //tmp//test.txt</Item>
<Item Name="Filter"/>
</Link>
It just opens a Terminal shell.

That's about all I'm able to get.

If you try it through the editor in 32.0.11 one arg should work. It does for me. I added a link to open the specified file with VLC.

The TextEdit.App is in the Program Path BTW. Not /bin/open

[MrBiff]

What I'm ultimately trying to do is get a Terminal window open, and have it run a shell command + args.

Since this doesn't seem to work, I created an AppleScript, to do what I'm trying to accomplish.  The script works fine on the command line, and does the right thing. 

So then I try setting the program path (both directly and by using Browse) to /usr/bin/osascript.   But the script is not invoked.  Browse sets single forward slashes, btw.  I'm guessing Browse navigates into the app bundles contents to get the binary's path.  Obviously a command line executable does not have this.

Here's an AppleScript you can try, save to your home dir as "test.applescript"

Code: [Select]

tell application "Terminal"
reopen
do script "echo arg1 arg2" in window 1
activate
end tell

Test on the command line such as:

Code: [Select]

osascript /Users/bob/test.applescript
Maybe you can get this to work. 

[bob]

That's not really what it's designed to do on Mac. The link is to an App. The system returns the App bundle then we call the App by it's bundle with the command line arg(s). It's up to the system to find the primary executable in the bundle and pass along the parameters to it setting capabilities based on the Apps plist.

Calling command line executables directly is a different matter. Perhaps that could be added.

[MrBiff]

That's not really what it's designed to do on Mac. The link is to an App. The system returns the App bundle then we call the App by it's bundle with the command line arg(s). It's up to the system to find the primary executable in the bundle and pass along the parameters to it setting capabilities based on the Apps plist.

Calling command line executables directly is a different matter. Perhaps that could be added.

Being able to launch an App is good.

Being able to launch command line Mach-O would bring this in line with MC for Windows, where it works.  And this was my original intent / need.  It opens the door to many capabilities.  So this is what I'm asking for.  I'm hoping this can be added.

[zybex]

I'm confused. Isn't it just a matter of starting the Terminal app with the appropriate args to execute a .sh script or a bash command?
The equivalent in windows is starting cmd.exe with some args, we can't just execute shell commands without invoking cmd or powershell.

[bob]

I'm confused. Isn't it just a matter of starting the Terminal app with the appropriate args to execute a .sh script or a bash command?
The equivalent in windows is starting cmd.exe with some args, we can't just execute shell commands without invoking cmd or powershell.

I actually don't know how that would work on Mac. Right now, the code only allows one arg because of the way the windows args to cmd.exe are specified.
I'm pretty sure that's not going to be the same on Mac

[bob]

I'm going to play with changing the behavior based on whether or not the program is a bundle.
If you use the browse command to an App you can get the bundle path otherwise typing in a command on the program line will allow posix style command execution.

[MrBiff]

Again, thank you.

Maybe it's time to provide support in Links (and perhaps Send To) that allow users to select powershell 5 or pwsh 7 (aka Core) as the shell that you invoke via CreateProcess*().  You could use then base64 encode the command arguments provided by the user, include the option -EncodedCommand, and this eliminates all quoting and shell meta-character ambiguity.  Users get true ARGV like behavior without all the garbage rules and limitations foisted on users for the past 30+ years.

[bob]

I'm going to play with changing the behavior based on whether or not the program is a bundle.
If you use the browse command to an App you can get the bundle path otherwise typing in a command on the program line will allow posix style command execution.

Ok so here is what will be in the next build.
The arguments for Mac (and linux) should be separated thusly

"arg1" "arg2" "arg3" and so forth. Expressions would be like this "[Filename]" as an arg.

If MacOS finds an bundled app in the path which would be the case if you used browse, it will pass the command and args to the App via the MacOS API.
If the path for the executable is not an app (you typed it in), we'll use the vfork call.
So for example, if I try a command of
/bin/ls
and args of
"-l" "[Filename]"
I see an extended listing of the file on standard output.

You are welcome to play around with this using shell, terminal, whatever and it should work as long as you get the args right.

[MrBiff]

I just tried this:

Code: [Select]

<Link version="1.2">
<Item Name="Name">/bin/ls</Item>
<Item Name="Action">0</Item>
<Item Name="Base URL"/>
<Item Name="Search URL"/>
<Item Name="Type">1</Item>
<Item Name="Program Path">/bin/ls</Item>
<Item Name="Program Parameters">"-l" "[Filename]"</Item>
<Item Name="Filter"/>
</Link>
but get no output in the Terminal that is launched.  Do you?

[bob]

I just tried this:

Code: [Select]

<Link version="1.2">
<Item Name="Name">/bin/ls</Item>
<Item Name="Action">0</Item>
<Item Name="Base URL"/>
<Item Name="Search URL"/>
<Item Name="Type">1</Item>
<Item Name="Program Path">/bin/ls</Item>
<Item Name="Program Parameters">"-l" "[Filename]"</Item>
<Item Name="Filter"/>
</Link>
but get no output in the Terminal that is launched.  Do you?

I see the output on Standard Out. Not in a terminal.
I haven't found a way to make the Terminal App run a command line.

You might look at this thread. I played around with some of it.
https://superuser.com/questions/16750/how-can-i-run-an-application-with-command-line-arguments-in-mac-os

[bob]

I see the output on Standard Out. Not in a terminal.
I haven't found a way to make the Terminal App run a command line.

You might look at this thread. I played around with some of it.
https://superuser.com/questions/16750/how-can-i-run-an-application-with-command-line-arguments-in-mac-os

There was an issue with paths that will be fixed in the next build. With the fix I can make this work:
Command
/usr/bin/open
Args
"-n" "-a" "/System/Applications/Utilities/Terminal.app" "--args" "/bin/ls"
for example.
However Terminal doesn't seem to accept more than one arg with --args. I can't find a way to make it do something like
/bin/ls -l
Even from just a terminal session.
At any rate this may not affect your use case.
Note also that you can use /usr/bin/open with an app bundle name instead of the path if you specify -b bundlename instead of -a apppath which with the current build would allow you to avoid the slash path issue.

[MrBiff]

Nice.  Thank you!

[bob]

Nice.  Thank you!

Great, thanks for the report.