Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
start.command problem on macOS
#1
I LOVE qb64pe, and would hate to live without it. I use it to streamline my computer activities, much as I did with batch files in the olden days. I've even used it to run industrial equipment (once did that with DOS too). But there are always little things, that take me forever to get around to fixing, and this was one of those.

The start.command files on my Mac never worked properly. After years of ignoring it I finally decided to dig in and fix it. Turns out to be simple. If the program filename has spaces in it, the start.command malfunctions. It's the second line in the file:

cd "$(dirname "$0")"
./Open Web Image &
osascript -e 'tell application "Terminal" to close (every window whose name contains "Open Web Image_start.command")' &
osascript -e 'if (count the windows of application "Terminal") is 0 then tell application "Terminal" to quit' &
exit  

Because the filename has spaces in it, it needs to be in quotes or have the spaces escaped out with backslashes:
./"Open Web Image" &   OR
./Open\ Web\ Image &

So I went into the support folder, opened the qb64pe.bas program, searched for "start.command", and found the issue on line 13043.
Here is the block of code involved:

IF INSTR(_OS$, "[MACOSX]") THEN
        ff = FREEFILE
        IF path.exe$ = "./" OR path.exe$ = "../../" OR path.exe$ = "..\..\" THEN path.exe$ = ""
        OPEN path.exe$ + file$ + extension$ + "_start.command" FOR OUTPUT AS #ff
        PRINT #ff, "cd " + CHR$(34) + "$(dirname " + CHR$(34) + "$0" + CHR$(34) + ")" + CHR$(34);
        PRINT #ff, CHR$(10);
        PRINT #ff, "./" + file$ + extension$ + " &";
        PRINT #ff, CHR$(10);
        PRINT #ff, "osascript -e 'tell application " + CHR$(34) + "Terminal" + CHR$(34) + " to close (every window whose name contains " + CHR$(34) + file$ + extension$ + "_start.command" + CHR$(34) + ")' &";
        PRINT #ff, CHR$(10);
        PRINT #ff, "osascript -e 'if (count the windows of application " + CHR$(34) + "Terminal" + CHR$(34) + ") is 0 then tell application " + CHR$(34) + "Terminal" + CHR$(34) + " to quit' &";
        PRINT #ff, CHR$(10);
        PRINT #ff, "exit";
        PRINT #ff, CHR$(10);
        CLOSE #ff
        SHELL _HIDE "chmod +x " + AddQuotes$(path.exe$ + file$ + extension$ + "_start.command")
    END IF

I changed the highlighted line to:
PRINT #ff, "./" +  CHR$(34) + file$ + extension$ + CHR$(34) +  " &";

After compiling and running the new qb64pe program, no more issues. I should have done this years ago. I hope this is useful to others as well. Maybe this could be incorporated in the next release, if it doesn't mess up Windows machines?
True, I could use underscores in filenames instead of spaces, but where's the fun in that?
Now if I can only find the time to change those copy and paste keystrokes...
Reply
#2
(04-28-2024, 02:52 AM)tothebin Wrote: I LOVE qb64pe, and would hate to live without it. I use it to streamline my computer activities, much as I did with batch files in the olden days. I've even used it to run industrial equipment (once did that with DOS too). But there are always little things, that take me forever to get around to fixing, and this was one of those.

The start.command files on my Mac never worked properly. After years of ignoring it I finally decided to dig in and fix it. Turns out to be simple. If the program filename has spaces in it, the start.command malfunctions. It's the second line in the file:

cd "$(dirname "$0")"
./Open Web Image &
osascript -e 'tell application "Terminal" to close (every window whose name contains "Open Web Image_start.command")' &
osascript -e 'if (count the windows of application "Terminal") is 0 then tell application "Terminal" to quit' &
exit  

Because the filename has spaces in it, it needs to be in quotes or have the spaces escaped out with backslashes:
./"Open Web Image" &   OR
./Open\ Web\ Image &

So I went into the support folder, opened the qb64pe.bas program, searched for "start.command", and found the issue on line 13043.
Here is the block of code involved:

IF INSTR(_OS$, "[MACOSX]") THEN
        ff = FREEFILE
        IF path.exe$ = "./" OR path.exe$ = "../../" OR path.exe$ = "..\..\" THEN path.exe$ = ""
        OPEN path.exe$ + file$ + extension$ + "_start.command" FOR OUTPUT AS #ff
        PRINT #ff, "cd " + CHR$(34) + "$(dirname " + CHR$(34) + "$0" + CHR$(34) + ")" + CHR$(34);
        PRINT #ff, CHR$(10);
        PRINT #ff, "./" + file$ + extension$ + " &";
        PRINT #ff, CHR$(10);
        PRINT #ff, "osascript -e 'tell application " + CHR$(34) + "Terminal" + CHR$(34) + " to close (every window whose name contains " + CHR$(34) + file$ + extension$ + "_start.command" + CHR$(34) + ")' &";
        PRINT #ff, CHR$(10);
        PRINT #ff, "osascript -e 'if (count the windows of application " + CHR$(34) + "Terminal" + CHR$(34) + ") is 0 then tell application " + CHR$(34) + "Terminal" + CHR$(34) + " to quit' &";
        PRINT #ff, CHR$(10);
        PRINT #ff, "exit";
        PRINT #ff, CHR$(10);
        CLOSE #ff
        SHELL _HIDE "chmod +x " + AddQuotes$(path.exe$ + file$ + extension$ + "_start.command")
    END IF

I changed the highlighted line to:
PRINT #ff, "./" +  CHR$(34) + file$ + extension$ + CHR$(34) +  " &";

After compiling and running the new qb64pe program, no more issues. I should have done this years ago. I hope this is useful to others as well. Maybe this could be incorporated in the next release, if it doesn't mess up Windows machines?
True, I could use underscores in filenames instead of spaces, but where's the fun in that?
Now if I can only find the time to change those copy and paste keystrokes...

Thank you for reporting and suggesting the fix. This is now merged into the GitHub repo and will be there in the upcoming release.

And yeah, I absolutely hate the constant switching between Ctrl + <whatever> and Command + <whatever> shortcuts in macOS when moving from QB64 to another app. It's seriously mental gymnastics. You get used to it after a while, only to figure out, that you got too used to it even after booting to Windows / Linux.  Big Grin

Please submit a GitHub issue about this if you get a chance.
Reply
#3
(04-28-2024, 08:37 PM)a740g Wrote:
(04-28-2024, 02:52 AM)tothebin Wrote: I LOVE qb64pe, and would hate to live without it. I use it to streamline my computer activities, much as I did with batch files in the olden days. I've even used it to run industrial equipment (once did that with DOS too). But there are always little things, that take me forever to get around to fixing, and this was one of those.

The start.command files on my Mac never worked properly. After years of ignoring it I finally decided to dig in and fix it. Turns out to be simple. If the program filename has spaces in it, the start.command malfunctions. It's the second line in the file:

cd "$(dirname "$0")"
./Open Web Image &
osascript -e 'tell application "Terminal" to close (every window whose name contains "Open Web Image_start.command")' &
osascript -e 'if (count the windows of application "Terminal") is 0 then tell application "Terminal" to quit' &
exit  

Because the filename has spaces in it, it needs to be in quotes or have the spaces escaped out with backslashes:
./"Open Web Image" &   OR
./Open\ Web\ Image &

So I went into the support folder, opened the qb64pe.bas program, searched for "start.command", and found the issue on line 13043.
Here is the block of code involved:

IF INSTR(_OS$, "[MACOSX]") THEN
        ff = FREEFILE
        IF path.exe$ = "./" OR path.exe$ = "../../" OR path.exe$ = "..\..\" THEN path.exe$ = ""
        OPEN path.exe$ + file$ + extension$ + "_start.command" FOR OUTPUT AS #ff
        PRINT #ff, "cd " + CHR$(34) + "$(dirname " + CHR$(34) + "$0" + CHR$(34) + ")" + CHR$(34);
        PRINT #ff, CHR$(10);
        PRINT #ff, "./" + file$ + extension$ + " &";
        PRINT #ff, CHR$(10);
        PRINT #ff, "osascript -e 'tell application " + CHR$(34) + "Terminal" + CHR$(34) + " to close (every window whose name contains " + CHR$(34) + file$ + extension$ + "_start.command" + CHR$(34) + ")' &";
        PRINT #ff, CHR$(10);
        PRINT #ff, "osascript -e 'if (count the windows of application " + CHR$(34) + "Terminal" + CHR$(34) + ") is 0 then tell application " + CHR$(34) + "Terminal" + CHR$(34) + " to quit' &";
        PRINT #ff, CHR$(10);
        PRINT #ff, "exit";
        PRINT #ff, CHR$(10);
        CLOSE #ff
        SHELL _HIDE "chmod +x " + AddQuotes$(path.exe$ + file$ + extension$ + "_start.command")
    END IF

I changed the highlighted line to:
PRINT #ff, "./" +  CHR$(34) + file$ + extension$ + CHR$(34) +  " &";

After compiling and running the new qb64pe program, no more issues. I should have done this years ago. I hope this is useful to others as well. Maybe this could be incorporated in the next release, if it doesn't mess up Windows machines?
True, I could use underscores in filenames instead of spaces, but where's the fun in that?
Now if I can only find the time to change those copy and paste keystrokes...

Thank you for reporting and suggesting the fix. This is now merged into the GitHub repo and will be there in the upcoming release.

And yeah, I absolutely hate the constant switching between Ctrl + <whatever> and Command + <whatever> shortcuts in macOS when moving from QB64 to another app. It's seriously mental gymnastics. You get used to it after a while, only to figure out, that you got too used to it even after booting to Windows / Linux.  Big Grin

Please submit a GitHub issue about this if you get a chance.
Okay, here's a stupid idea... Command+C, Command+X, and Command+V don't appear to do anything in the IDE. So why not make the copy shortcut BOTH  Ctrl+C and Command+C? It won't matter what system you are used to because they both work. 

Rank amateur here, how do I go about submitting a GitHub issue?
Reply
#4
Hey tothebin. Rank amateur here too, but I've at least done this before. Make your way to: 

https://github.com/QB64-Phoenix-Edition/QB64pe

You'll have to open an account probably, but then once at the GitHub QB site above click on "Issues," then "New Issue" and then it's pretty self-explanatory. Good luck!
Reply




Users browsing this thread: 1 Guest(s)