macOS Services Quick Action w/Shell script -dealing with files

[macstatic]

I'm working on a MacOS "Services" Quick Action for converting H.265 (HEVC) videos to H.264 (using FFMPEG), but I'm having some minor issues regarding file naming and file-location.
I've created a "Quick Action" in Automator which consists of a shell script and an Applescript.

The shell script looks like this:

# set FFMPEG path
export PATH="$PATH:/usr/local/bin"

#!/bin/sh

for f in "$@"
do
 
ffmpeg -i "$f" -movflags use_metadata_tags -map_metadata 0 -c:v libx264 -profile:v high -preset slow -tune film -crf 18 "CONVERTED.mp4"
done

Naming
When having selected the (H.265) videos in the Finder, right-clicked and chosen the Service I'm working on here I basically want the files to be copied, converted to H.264 and named using the same name as before, but "_converted" added to it (i.e. "video.mov" becomes "video_converted.mp4").
I'm not sure if FFMPEG understands .MOV files so based upon some online examples I found I chose to have it output to .MP4 instead. But I may be wrong and will take a further look into that later.
I also want to ensure that the script won't mess files up in case I mistakingly select some other file-types in the Finder, but I think I've taken care of that with the very first option in the workflow (Workflow receives current [movie files] in [Finder] -see screenshot above). Does it suffice?

File location
In addition to the output name I want it to end up in the same location as the original file. Currently it ends up in the root of my Mac-user folder for some reason.

Progress bar
When the Service runs it may take a while for long videos to get converted, and seemlingly nothing is going on (except for a tiny spinning cogwheel in the Finder's menu-bar). I've added an Applescript at the end of the process which confirms that the file has been converted, but that doesn't help the user see that something is going on until then.
Is there a way to add a progress bar or something similar?

FFMPEG -changes the datestamp
Perhaps slightly off-topic, but for some unknown reason the timestamp gets changes to exactly 2 hours behind the original file's timestamp.
This forum thread explains that the following (which I've used) keeps the time/date the same as the original file:

"-movflags use_metadata_tags -map_metadata 0"

An estimated guess would be that it has something to do with time-zones.

UPDATE: Using Exiftool to read all relevant EXIF info about a file (in the Terminal app: exiftool filename.mov), I compared an original video (H.265) with a converted copy (H.264) and found out that the converted copy had one tag added which the original didn't have at all:

Creation Time : 2023-05-17T10:07:48.000000Z

However, both files had the "creation date" tag with the exact same information:

Creation Date : 2023:05:17 12:07:48+02:00

As you can see, the "creation time" tag shows a time difference of exactly two hours, and it seems Lightroom (which is my go-to app for my photo organizing needs) uses that tag if it's available.
Perhaps I could solve the problem by having Exiftool remove it after FFMPEG is done with its thing, as part of the script (or better yet: tell FFMPEG somehow not to add that tag in the first place).
But I'm really just guessing here and would like to have things confirmed by more knowledgeable people than myself first.

 

[Red Menace]

The shell script action just uses a default shell, so it is up to you to do things such as setting the environment or working directory.

The system's ScriptMonitor application is what is putting that statusItem in the menubar, and progress is shown differently depending on whether it is a script, application, workflow, in an editor, etc. For Automator it just shows the progress of the workflow itself, e.g. how many actions have been completed, not what any particular action is doing. AppleScript's built-in progress stuff can be used, but in a workflow that would also be placed in the statusItem. Script progress indicators are a royal pain, for whatever reason, the easiest is to just use a third party background app such as SKProgressBar that is independent from whatever is calling it.

 

[macstatic]

Thanks @Red Menace.
I'll take a closer look at SKProgressBar which sounds like a good solution. On the other hand, wouldn't that make the script less portable (i.e. usable for others) unless they too install that 3rd party app?
Unless of course it just skips it if it's not available and lets the rest of the script run as normal, but without the "enhancement" of a progress indicator?

I've been trying to find a solution for the syntax of the converted file (use the same name as the original file but with "_converted" added at the end, and have it saved to the same location as the original file), but no matter what I do I can't get the syntax right or find any good online guides on the matter. It's probably just a misplaced quote character, bracket or something..... Can someone give me some pointers, or some good websites to learn about those issues?

 

[Red Menace]

SKProgressBar can be used for personal, non-commercial purposes and can be distributed, copied or uploaded, so if that is your purpose then it can be added to your application/script bundle resources. If not, there are a few progress indicator scripts out there, I even have one using AppleScriptObjC that could be made into a script library (script libraries can also be added to application or script bundle resources), although it wouldn't be as good as something by a regular developer, even after I blow off all the dust.

You can `cd` to the containing directory to make it the working directory. Don't know what you are doing for the name, but it includes the extension, so you would need to split up the file path and recombine the pieces as desired - a shell script example would be something like:

#!/bin/bash

for path in "$@"
do
   # get the pieces
   name="${path##*/}"
   dir="${path%$name}"
   base="${name%.[^.]*}"
   ext="${name:${#base} + 1}"

   # show the pieces
   echo " '$path'
    directory = '$dir'
    basename  = '$base'
    extension = '$ext' "

   # combine the pieces   
   echo " '${dir}${base}_converted.${ext}' "
done

 

[!!!]

I would recommend

if [ "$(ffprobe -v error -select_streams v:0 -show_entries stream=codec_name -of default=noprint_wrappers=1:nokey=1 "$file")" != "hevc" ]; then
    ffmpeg -i "$file" ... "${file%.mov}_converted.mp4"
fi

To both verify the file is HEVC and fix the filename. You could check if the file is not h264 instead.

It seems like the creation date is an issue with ffmpeg, where it's reinterpreting the timestamp and then changing the timezone (and adjusting the date accordingly). And it seems like the software you're using doesn't play nicely with that (either ffmpeg is incorrectly formatting it or your software just isn't handling the timezone conversion).

If you insert this into the loop after the ffmpeg command (and remove now redundant ffmpeg metadata flags), exiftool will overwrite your file with the exact metadata from the source file. I strongly recommend you test this thoroughly, I have not used this part in my scripts for many years. As it says, it overwrites the file (in this case "original" means the original destination file, so the mp4. If you omit that flag it will create a new file with the metadata next to the converted mp4)

exiftool -ExtractEmbedded -TagsFromFile "$file"  -all:all -overwrite_original  "${file%%.mov}"_converted.mp4

As for the progress bar, ffmpeg outputs text of its current time (or frame) position in the video. You could call ffprobe to get the total duration (or frame, again), parse the output, and then calculate a progress bar from that. I believe you can interface directly wtih ffmpeg using C/C++ directly, but that's a bit of an undertaking. You might want to look into HandBrakeCLI instead, I don't know if it offers any kind of progress bar but it's often a bit more user-friendly.

 

[macstatic]

Thanks guys! I finally solved two of my main problems, thanks to your code and a lot of trial and error to get the syntax right
I was hoping to find some good explanation online for this, but found very little -perhaps I just searched for the wrong thing, but picked up a little here and there from script examples in various forum discussions.

The converted filename is now correct and is saved in the same folder as the original. The script also works fine with multiple files. Here's what it looks like now:

# set FFMPEG path
export PATH="$PATH:/usr/local/bin"

#!/bin/bash

for f in "$@"
do
ffmpeg -i "$f" -movflags use_metadata_tags -map_metadata 0 -c:v libx264 -profile:v high -preset slow -tune film -crf 18 "${f%.*}_converted.mp4"
done

SKProgressBar can be used for personal, non-commercial purposes and can be distributed, copied or uploaded, so if that is your purpose then it can be added to your application/script bundle resources.

I didn't know that.
So I can embed it into the "Quick Action" file that I'm creating within Automator?
I was only thinking about sharing my ending result here (if successful) in case others would find it useful to have on their Mac.

You can `cd` to the containing directory to make it the working directory. Don't know what you are doing for the name, but it includes the extension, so you would need to split up the file path and recombine the pieces as desired - a shell script example would be something like:
[......]

I'm sorry for my silly question, but what should the code you wrote do?
Is it a better solution to where the file/files are saved than what I've used in my code above?

I would recommend

if [ "$(ffprobe -v error -select_streams v:0 -show_entries stream=codec_name -of default=noprint_wrappers=1:nokey=1 "$file")" != "hevc" ]; then
    ffmpeg -i "$file" ... "${file%.mov}_converted.mp4"
fi

To both verify the file is HEVC and fix the filename. You could check if the file is not h264 instead.

Yes! Safety features are good to have.
I might have misunderstood what you meant here, but tried inserting the above in a script on its own, then running it on a H265-encoded video. I got a lot of error messages.
Same result for a H265-encoded video.

Is this a safety check which skips the converting if the file is already H264?
If so, how do I incorporate it into my existing code which does the converting itself?

It seems like the creation date is an issue with ffmpeg, where it's reinterpreting the timestamp and then changing the timezone (and adjusting the date accordingly). And it seems like the software you're using doesn't play nicely with that (either ffmpeg is incorrectly formatting it or your software just isn't handling the timezone conversion).

Yes, Lightroom is problematic with these files, but Photos on the other hand shows the exact same time and date of the converted (H264) file as the original!
I'm looking into Lightroom and how it handles metadata, and which tags it expects, and likewise if there are options for the metadata in FFMPEG which I've misunderstood the use of.

If you insert this into the loop after the ffmpeg command (and remove now redundant ffmpeg metadata flags), exiftool will overwrite your file with the exact metadata from the source file.

exiftool -ExtractEmbedded -TagsFromFile "$file"  -all:all -overwrite_original  "${file%%.mov}"_converted.mp4

If I understand you correctly this means that the script will then have FFMPEG convert the file to H264, then EXIFtool will take over to copy the time/date (and other metadata) over from the source file, and finally the converted file will be saved?

As for the progress bar, ffmpeg outputs text of its current time (or frame) position in the video. You could call ffprobe to get the total duration (or frame, again), parse the output, and then calculate a progress bar from that. I believe you can interface directly wtih ffmpeg using C/C++ directly, but that's a bit of an undertaking. You might want to look into HandBrakeCLI instead, I don't know if it offers any kind of progress bar but it's often a bit more user-friendly.

I tried Handbrake for the converting but found it complicated in addition to getting the same time/date problem as with FFMPEG. That's why I decided to try and create a Services.

As for FFprobe; for some reason this isn't getting installed on my Mac (MacOS 10.14 Mojave). From what I've read it should be part of the FFMPEG installation, but at least with brew it doesn't include it.
I've tried uninstalling both brew and FFMPEG, then reinstalling them both again, cleaning up brew, updating etc. but no matter what I do there's no FFprobe to be found.
Apparently others using Mojave have had the same problem. I tried the suggestions given, but it didn't solve anything here.
I read here that the Xcode version supplied with Mojave is old and outdated, so that may be it, but wouldn't brew update it when reinstalling or doing an update?
Finally, I read about someone else having problems with the installation of FFMPEG not including FFPROBE, but despite doing everything suggested there I still don't have FFPROBE.

 

[!!!]

I might have misunderstood what you meant here, but tried inserting the above in a script on its own, then running it on a H265-encoded video. I got a lot of error messages.

Sorry, I had a typo, it was checking if the file wasn't hevc. The code block at the end of my comment should be fixed.

Is this a safety check which skips the converting if the file is already H264?
If so, how do I incorporate it into my existing code which does the converting itself?

Yes, it checks if the file is h.264, and if it is, it does not convert it. I have added code to print out a message if the file is found to be h.264. You can delete it or comment it out if you want.

If I understand you correctly this means that the script will then have FFMPEG convert the file to H264, then EXIFtool will take over to copy the time/date (and other metadata) over from the source file, and finally the converted file will be saved?

Adding in exiftool would be a discrete step, after ffmpeg. Exiftool will read the metadata from the source file "$f", then read the contents of the converted file, "${f%.*}_converted.mp4", then write a new temporary file with the metadata from the first and the contents of the second. Finally, if you have the overwrite original flag set, it will overwrite the "${f%.*}_converted.mp4" file with its temporary file.

#!/usr/bin/env bash

# set FFMPEG path
export PATH="/usr/local/bin:$PATH"

for f in "$@"
do
if [ "$(ffprobe -v error -select_streams v:0 -show_entries stream=codec_name -of default=noprint_wrappers=1:nokey=1 "$f")" != "h264" ]; then
    ffmpeg -i "$f" -movflags use_metadata_tags -map_metadata 0 -c:v libx264 -profile:v high -preset slow -tune film -crf 18 "${f%.*}_converted.mp4"
# here you would add the exiftool command, like this: (uncomment it to activate it:
      # exiftool -ExtractEmbedded -TagsFromFile "$f"  -all:all -overwrite_original  "${f%.*}_converted.mp4"
else
    echo "File is H.264, not converting."
fi
done

I have moved the shebang (#!) to the top, and I use the preferred method with env. This helps with compatibility as you're not dependent on a specific bash installation. Personally, I'd recommend installing a more recent bash via homebrew or macports, as the one provided by macOS is very old.

Additionally, I've set your ffmpeg path to be before any other provided paths. This ensures that the copy of ffmpeg you want to use is actually used. In the future, I'd recommend setting up your paths file in `/etc/paths`. I assume you are using an Intel Mac with homebrew. If, in the future, you get an AS Mac, you'll likely want to use the AS build of ffmpeg, in which case you'd have to change every script with the new ffmpeg path. If you modify the /etc/paths file directly, shell scripts will use that instead of relying on their own incarnation. Basically, the script itself setting the path is brittle, and you should prefer to rely on OS-provided configuration files (that's their entire point).

 

[Red Menace]

In the future, I'd recommend setting up your paths file in `/etc/paths`.

Automator's Run Shell Script action uses a default shell, so you would still need to use full paths, import, or otherwise set up the environment. Probably be better to just try to find ffmpeg and exiftool in the possible locations.

 

[macstatic]

Yes, it checks if the file is h.264, and if it is, it does not convert it. I have added code to print out a message if the file is found to be h.264. You can delete it or comment it out if you want.

Thanks.
I've now uncommented the EXIFtool part and disabled the Applescript part I had from before (in case that would interfere with the script, seeing that you have alerts in the code as well).
Your updated script appears to work fine as far as converting to H.264 goes, but I don't understand how the "check for H.264 -if yes, don't convert again" works.....

- If I take a H265 file and convert it I get a resulting H264 file with "_converted.mp4" added to the original filename
- If I take the same H265 file and convert nothing appears to happen (except the spinning cogwheel in the Finder menubar) but its "Date created", "Date modified" and "Date added" columns in the Finder (List view) all get updated to the current time, indicating the file has become overwritten
- If I take the already converted file (i.e. now H264 encoded and with a "_converted.mp4" filename), then try to convert it I end up with a new H264 file (but with a "_converted_converted.mp4" filename. Strangely the new file is slightly smaller than the first one (with the file I tested they are 4.5 and 4.3MB)

So for some reason the H264-checking doesn't work (or I've misunderstood). And there's also no message that pops up. Should a Finder window pop up with that message, just like the one I already had using the Applescript that follows the shell script), or in a Terminal window?

Could the problem be due to not having ffprobe?
I see there's reference to ffprobe in your script, but I don't have it installed (and don't understand how I can get it). Here's what the Terminal app tells me:

$ ffprobe
-bash: ffprobe: command not found
$ man ffprobe
No manual entry for ffprobe

Adding in exiftool would be a discrete step, after ffmpeg. Exiftool will read the metadata from the source file "$f", then read the contents of the converted file, "${f%.*}_converted.mp4", then write a new temporary file with the metadata from the first and the contents of the second. Finally, if you have the overwrite original flag set, it will overwrite the "${f%.*}_converted.mp4" file with its temporary file.

Thanks for explaining.
Unfortunately the "Capture time" is still -2 hours compared to the original (H265) file. I think I need to gather as much information about the metadata tags and options of FFMPEG and EXIFtool that I can, and do some serious testing with that.
Although frustrating I can't see why it won't be possible to just have the same metadata (except the file timestamps of course) copied over to the destination file. I'm sure there's an explainable reason for the -2 hour glitch happening, but I see it takes some researching to figure out. Also I need to find out more about Lightroom and its handling of metadata.

I have moved the shebang (#!) to the top, and I use the preferred method with env. This helps with compatibility as you're not dependent on a specific bash installation. Personally, I'd recommend installing a more recent bash via homebrew or macports, as the one provided by macOS is very old.

Thanks for letting me know. I'll try to get that done soon.
Which implications can I risk running into if I just continue using the version I currently have (see below)?

$ which bash
/bin/bash
$ bash -version
GNU bash, version 3.2.57(1)-release (x86_64-apple-darwin18)
Copyright (C) 2007 Free Software Foundation, Inc.

Additionally, I've set your ffmpeg path to be before any other provided paths. This ensures that the copy of ffmpeg you want to use is actually used.

What is the difference between between
export PATH="$PATH:/usr/local/bin" (which I had used)
and
export PATH="/usr/local/bin:$PATH" (which you've used here) ?

I understand the reason for defining the path is to let the script find FFMPEG (and EXIFtool).

In the future, I'd recommend setting up your paths file in `/etc/paths`.

I looked up the /etc/ folder and found a file named "paths" (with no extension). Opening it up in Textedit showed me the following content:

/usr/bin
/bin
/usr/sbin
/sbin
/usr/local/bin

I see that /usr/local/bin/ is there already. Does this mean I don't need to do any changes to that file?

I assume you are using an Intel Mac with homebrew.

Yes, correct.

If, in the future, you get an AS Mac, you'll likely want to use the AS build of ffmpeg, in which case you'd have to change every script with the new ffmpeg path. If you modify the /etc/paths file directly, shell scripts will use that instead of relying on their own incarnation. Basically, the script itself setting the path is brittle, and you should prefer to rely on OS-provided configuration files (that's their entire point).

Aha! So if I get a new Apple Silicon-based Mac I only need to edit its /etc/paths file and I can continue to use the scripts I've been using with my previous Intel Mac?

 

[Greybeard2017]

I don't fully understand your datetime issue - Norway is GMT+2 so they seem reasonable.

I'd recommend when you view metadata with exiftool to do something like:

exiftool -a -G1 -s Time:All <filename>

this will give you the actual tagnames together with the group and it will dump all timestamps

it is quite possible that the file has multiple CreateDate tags in different groups

 

[macstatic]

exiftool -a -G1 -s Time:All <filename>

this will give you the actual tagnames together with the group and it will dump all timestamps

it is quite possible that the file has multiple CreateDate tags in different groups

Thanks. I did the above with both the original (H265) file and the converted (H264) file to compare them.
Only the converted file has the "CreationTime" tag which is displayed like this after issuing the above command:

[Keys]          CreationTime                    : 2018-09-12T19:47:53.000000Z

I read somewhere that I could check a specific tag with "exiftool -TAGNAME FILENAME.MP4", so I tried that with both files:

$ exiftool -creationtime IMG_0017_converted.mp4
Creation Time                   : 2018-09-12T19:47:53.000000Z
$
$ exiftool -creationtime IMG_0017.mov
Warning: [minor] The ExtractEmbedded option may find more tags in the media data - IMG_0017.mov
$

I located the "CreationTime" tag in the EXIFtool documentation for QuickTime tags, and it's apparently writeable, so I conclude that means it can also be deleted. I read somewhere online that you can delete a single tag from a file using adding an equal symbol after the tagname without any new value ("exiftool -TAGNAME= FILENAME.MP4") which is what I tried, but apparently didn't succeed:

$ exiftool -creationtime= IMG_0017_converted.mp4
    0 image files updated
    1 image files unchanged
$

I was hoping to compare the original and converted (with the above tag removed) files in Lightroom to see if this solved the issue.

 

[Greybeard2017]

I don't have a file to test with but try this:

exiftool -keys:creationtime= IMG_0017_converted.mp4

 

[macstatic]

$ exiftool -keys:creationtime= IMG_0017_converted.mp4
Warning: Sorry, keys:CreationTime doesn't exist or isn't writable
Nothing to do.
$

But the Exiftool docs for QuickTime says this tag is writeable.

I also tried adding "-overwrite_original" as I read somewhere that this actually saves the changes to the file, but that didn't help either:

$ exiftool -keys:creationtime= -overwrite_original IMG_0017_converted.mp4
Warning: Sorry, keys:CreationTime doesn't exist or isn't writable
Nothing to do.
$ exiftool -creationtime= -overwrite_original IMG_0017_converted.mp4
    0 image files updated
    1 image files unchanged
$

 

[Greybeard2017]

Well first figure out if its writeable or doesn't exist - if the following gives a result then it exists:

exiftool -keys:creationtime IMG_0017_converted.mp4

"I also tried adding "-overwrite_original" as I read somewhere that this actually saves the changes to the file"

No - changes are saved either way - if you use -overwrite_original then ExifTool updates the file without a backup - otherwise it saves the original file as the same name with "_original" suffix.

If you want me to test your file then you can post a DropBox link via PM

 

[macstatic]

Well first figure out if its writeable or doesn't exist - if the following gives a result then it exists:

exiftool -keys:creationtime IMG_0017_converted.mp4

Sure. Here's what it says:

$ exiftool -keys:creationtime IMG_0017_converted.mp4
Creation Time                   : 2018-09-12T19:47:53.000000Z
$

"I also tried adding "-overwrite_original" as I read somewhere that this actually saves the changes to the file"

No - changes are saved either way - if you use -overwrite_original then ExifTool updates the file without a backup - otherwise it saves the original file as the same name with "_original" suffix.

Ah, I see. Thanks for clarifying.
Since I still have the original (H265) file and am already working on the copy (converted to H264) where I also want the mentioned tag removed I'll just skip using "-overwrite_original".

If you want me to test your file then you can post a DropBox link via PM

Thanks, but I'll give it some more testing here first.
Just to make sure there wasn't something wrong with the file in question I converted another video as well, but got the same result:

$ exiftool -keys:creationtime IMG_0682_converted.mp4
Creation Time                   : 2023-05-17T10:07:48.000000Z
$
$ exiftool -keys:creationtime= IMG_0682_converted.mp4
Warning: Sorry, keys:CreationTime doesn't exist or isn't writable
Nothing to do.
$ exiftool -creationtime= IMG_0682_converted.mp4
    0 image files updated
    1 image files unchanged
$

And no -the file(s) aren't write-protected (if that's what the error message is referring to) in the Finder.

UPDATE: I'm finally getting somewhere!
I've tried removing a number of tags with EXIFtool to see if that makes any changes in Lightroom's display of metadata. Strangely, if I remove the "CreateDate" with EXIFtool it changes Lightroom's "Date time digitized" to 00:00:00 and 01/01/1904. Here are some screenshots from Lightroom and text-dumps from the Terminal:

First, the original (H265) file:

$ exiftool -Createdate IMG_0083.mov
Create Date                     : 2018:11:17 10:39:00
$

Next, the converted (H264) file, but otherwise unchanged metadata:

$ exiftool -Createdate IMG_0083_converted_untouched.mp4
Create Date                     : 2018:11:17 10:39:00
$

Finally, the converted (H264) file, but with the "CreateDate" tag removed using EXIFtool:

$ exiftool -CreateDate= IMG_0083_converted.mp4
    1 image files updated
$
$ exiftool -Createdate IMG_0083_converted.mp4
Create Date                     : 0000:00:00 00:00:00
$

I was expecting the tag to be actually removed using "-TAGNAME= "in EXIFtool, but apparently it just resets things to zero. Strange.
But I noticed something else of interest: here, the time-shift between the original (H265) file and the converted (H264) file is just -1 hour, while in another file I was working on before it was -2 hours. It just dawned to me that the -2 hour shift was from May while the -1 hour shift was from November, so this points to daylight savings.

 

[!!!]

Automator's Run Shell Script action uses a default shell, so you would still need to use full paths, import, or otherwise set up the environment. Probably be better to just try to find ffmpeg and exiftool in the possible locations.

That's interesting. I don't use Automator, so I had (incorrectly) assumed it runs like any other shell script. For reference, editing /etc/paths works with double-clicking any other shell script, whereas .bash_profile edits do not, which is why I typically recommend it.

/usr/bin:/bin:/usr/sbin:/sbin

Appears to be the entirety of Automator's shell path.

---

Could the problem be due to not having ffprobe?

Yes. It uses ffprobe to extract the codec of the file. You can add "set -o errexit" above your for loop in the script to have the script exit if it fails. Unfortunately this means that if one conversion fails, the rest will not execute. This is a limitation of shell scripting.

Additionally, Automator won't by default display any messages. I found that it's possible to set the output of a Run Shell Script to a variable, then to display the variable. The output from ffmpeg will be too long, and Automator does not appear to capture Standard Error. You can fix these with more shell scripting, but it's a bit involved.

What is the difference between between
export PATH="$PATH:/usr/local/bin" (which I had used)
and
export PATH="/usr/local/bin:$PATH" (which you've used here) ?

The order of the paths matter, as the first one takes precedence over latter paths. If it finds ffmpeg in the existing part of the path it will use that instead of the one in /usr/local/bin. Doesn't really matter given the new info about Automator's paths.

Some argue that you should keep the system provided paths first, to keep compatibility with existing scripts. In my experience, however, almost all the scripts/commands I have come across where this matters are ones that expect the GNU/Linux version of commands, where macOS's BSD commands to not share complete feature parity. Additionally, if you use Python, this would prevent you from accidentally using macOS's ancient Python installation when that was still a thing.

Aha! So if I get a new Apple Silicon-based Mac I only need to edit its /etc/paths file and I can continue to use the scripts I've been using with my previous Intel Mac?

In theory, but alas Automator does not read that and is stuck with static paths.