I am running a bash script to do an rsync back on a computer running MacOS High Sierra. This is the script I am using,
#!/bin/bash
# main backup location, trailing slash included
backup_loc="/Volumes/Archive_Volume/00_macos_backup/"
# generic backup function
function backup {
echo " " >> $1
echo " " >> $1
echo "***** new log entry *****" >> $1
date >> $1
rsync -v -a -b --suffix=.back -E --log-file=$1 $2 $3
}
echo "starting backup script"
echo " "
# backup /Users/my_user/ to /Archive_Volume/00_macos_backup/
echo "backing up home"
logfile_path=$backup_loc"/rsync_log/01_home_log.txt"
backup_src_path="/Users/my_user"
backup_destination_path=$backup_loc
backup $logfile_path $backup_src_path $backup_destination_path
echo " "
echo "backup completed"
echo ""
echo " "
echo -n "press enter to exit script"
read exit_response
exit
There are other calls to the backup function after the home backup. The script seems to work, but when I key enter, instead of the terminal window closing like it does in windows under cygwin, I get the following message,
The terminal does not seem to function anymore but it does not close and I have to manually close it. It's not the end of the world but I don't understand why it doesn't close down on the exit command. Can anyone explain how to fix this?
In windows, I perform, Send to > Desktop (create shortcut) on the script file, which lives in /cygwin/usr/local/bin. I then modify the properties of the shortcut to,
Target: C:\cygwin\bin\sh.exe /usr/local/bin/data_backup.sh
Start in: C:\cygwin\bin
Run: Normal Window
When I want to run the backup, I double-click on the desktop shortcut. I also have an entry for the shortcut in Task Scheduler so that it runs every night. I could schedule with cygwin cron, but the windows scheduler is already running anyway and I didn't see the need to start a second daemon for just one task. This doesn't always work in windows 7 for some reason. The task appears in the schedule as active, but the script never runs. I have a second shortcut that runs a backup to an external device. For that script, I have to enter the drive letter of the external device after it is attached. Both scripts have an option to shutdown the computer after the backup is finished.
The process is similar in MacOS. I create an alias of the script in the script directory. For the alias file, I right click > open with > other. Then I select "All Applications" from the drop down menu (instead of the default "Recommended Applications", and then select "Terminal", "always open with", and then "open". This opens the script via the alias and runs it, which is annoying. I have to comment out most of the script first, or sit through the backup. There doesn't seem to be an easy way to indicate "open with" without actually opening.
Once this is done, I move the alias to the desktop and change the icon to something appropriate. I can then run the script by double clicking on the icon. MacOS doesn't seem to have any kind of launcher like most Linux distros. Launchers had vanished from Linux in some places as well, which is the type of thing I just can't understand. Why remove a useful functionality and force users to launch applications the way some programmer somewhere thinks they should be launched? What possible harm could it do to just leave it for those who want to use it?
How was the window in which the backup script runs on macOS created?
[/quote]
I'm not really sure about this. I presume that the OS opens the terminal and runs the script in the terminal. In windows, there are some window options in the shortcut properties. There is nothing like this in MacOS. Since MacOS is using an alias, my guess it that Finder opens the terminal window.
I got an email from a friend who uses MacOS much more often than I do and he said that I may be able to adjust the preferences for Terminal so that windows close when the terminal completes whatever process it it running. I will check on that and report back.
in Finder go to the directory containing the script I just created,
then right click on the name of that script, and
select "Make Alias"
it creates a new file in the same directory with the name script alias (where script is the name of the file I right-clicked on in Finder ) with the name of that file selected. I can then enter a new name for that alias or change the focus it I want to keep that name for the alias.
Note that I did not need to run the script to create the alias.
If I then double-click on the name of the alias in Finder , it opens a new window, runs the script in that window, and when the script exits, the window disappears.
If I move the file created onto my desktop and double-click on it there, macOS opens a new window, runs the script in that window, and when the script exits, the window disappears.
In either of the above cases, the window is running an interactive shell and can accept keyboard input in response to prompts issued by the script. If the script isn't expecting user input, I can minimize the window or move it behind other open windows and it will continue running until the script exits (and then the window disappears). Is that what you want to have happen?
This is the same process I used to create the alias (on MacOS 10.13.6, a bit behind yours).
It was not creating the alias that required me to run the script. When I double click on my alias, the script opens in Text Editor instead of running in Terminal. Unlike a windows shortcut or Linux launcher, the alias doesn't have a property to let you specify the program you want to open the file in. In order to get the script to run in Terminal, I had to do the steps I described to define "open with" for the script file (not the alias file). This is the procedure where I had to actually run the script in order to specify the "open with" program. Once I had done that, I could double click on the script (or on the alias) and it would run in Terminal. I actually don't know if this now applies to all files on the system with the .sh extension, or just the one script file. The alias works in any location where it's located. I believe this is just a symbolic link like ln.
After having set the "open with" value for the script file, when I double click on the alias file, a terminal window opens, the script runs, and finishes, but I get the [Process completed] message and the Terminal sits there in a non-functional state without the window closing.
This is what I want, I just don't know why the Terminal window closes when the script is finished on your system and stays open on mine. I have run this script on both windows and linux for a long time and I have never seen that before.
The fact that you have to take an intermediate step to specify what is to be used to run your script tells me that something is wrong. I'm guessing that you skipped part of the 1st step I mentioned in post #5. Please show us the output from the commands:
ls -l script
head script
where script is the name of the file containing your shell script.
If the mode of script doesn't allow you to execute it OR if the first line of script isn't #!/path/to/interpreter , then script is not an executable shell script file.
The link Finder is creating for me is not a hard link as would be created by ln nor a soft link as would be created by ln -s ; it is a binary executable file that directly invokes terminal to run script or to run /path/to/interpreter /path/to/script .
My-iMac:rsync_backup my_user$ ls -l
total 392
-rwxrwxrwx@ 1 my_user staff 88056 Mar 5 20:22 data_backup_icon.png
-rwxrwxrwx@ 1 my_user staff 102078 Mar 5 20:24 external_backup_icon.png
-rwxrwxrwx@ 1 my_user staff 1314 Mar 6 22:26 rsync_data_backup.sh
-rwxrwxrwx@ 1 my_user staff 1794 Mar 5 23:11 rsync_external_backup.sh
My-iMac:rsync_backup my_user$ head rsync_data_backup.sh
#!/bin/bash
I also did which just to make sure that bash was were it was expected.
My-iMac:rsync_backup my_user$ which bash
/bin/bash
How would MacOS know to read the first line and use that to know that the file is a script that should be run in bash. Is that the default behavior for any file with a .sh extension or does Finder read the first line of every file it opens to look for #! ? I believe that you can set the "open with" preference in the file Get Info window as well as in finder.
As far as I can tell with what you are saying, my script file should run in Terminal by double clicking without having to do anything special. I think the problem may be that the first application I opened the file with was the Atom editor and possibly that application did something to set the OS to open .sh files in the editor. My guess is it must be something like that. It runs now as it should.
I was told that I can get the terminal window to close when the script finished by setting a preference in Terminal preferences. It would make sense that this is a MacOS Terminal configuration issue and not an issue with the script or the way the script and window are created.
The backup is running now and I will check on the preferences when the backup is finished.
You name your shell script rsync_data_backup.sh and you have problems.
I name my shell script rsync_data_backup and it works just fine.
I don't know why, but having the extension .sh on your filename creates the problem you're having. Get rid of that extension and get rid of your problem.
When I remove the extension, the file icon changes from the Atom text editor icon to the terminal icon. The script does work as expected now. I wonder if MacOS reads the first line of a file that doesn't have an extension to see what to open the file with.
I'm having allot more fun now than I was with this yesterday.
On the issue of the window not closing when the script completes, if you go to Terminal > Preferences > Shell , there is a menu in the middle of the window called
when the shell exits .
There are three options on this menu,
close the window close if the shell exited cleanly don't close the window
mine was set to don't close the window
There are certainly cases where I would prefer to have the window stay open when the script has finished and I usually add a read statement to the end if this is the case. I'm not really sure it makes sense for that to be a global behavior since I can't see that I would want the same behavior in every script. It would be nice if exit had some options so you could specify this on a script by script basis.
There are also options in the Shell preference pane to indicate situations where ask before closing is implemented, in case that is of interest to anyone.
My apologies for not investigating this the other day, I forgot all about it.
exit does have an option for exactly the purpose of informing the thing which called it, it returns a number 0 for success and 1-127 for various errors. I suspect that's what "close if the shell exited cleanly" is about. exit 0 to close cleanly and exit 1 to make the terminal wait and display what happened.
Drawback is, if these scripts are called by anything else, nonzero means error, not just close/not close. crontab sends emails when programs exit nonzero, for example.
Perhaps your scripts could take a --terminal commandline switch which tells them to exit nonzero?
