We have a new IT department, and they have gone from waiting years to allow users to update to newer systems, and always staying a major release behind, to insisting (or at least encouraging) users to install the latest version.
The new macs we’re getting are installed with Monterey 12.3.1 and they don’t want to go back to Big Sur on them (which is what I’m using).
So, my question is, using Script Debugger, and scripting: inDesign; PhotoShop; Illustrator; Transmit; Outlook; Excel; Chrome; Safari; BBEdit; FastScripts; and a few others, am I going to hit any major roadblocks? Will it become difficult to distribute scripts?
It only matters for apps. If you distribute them directly – USB sticks, via network, etc – you should be fine. Otherwise you will need to Notarize them.
Notarizing can be a pain. Supporting people trying to use unnotarized apps can be a bigger pain.
The first issue I’ve come across is unstuffing “.sit” files. Our vendor distributes data that way and I’ve been using StuffitExpander to open them.
But in Monterey the command returns an error that I don’t have permission to move the file. I confirmed in finder that permissions are correct, and there’s no issue opening them from the UI. If I send the command to Finder to open them I get a file saving dialog, that is too disruptive for this workflow.
I’m not seeing two of the three dictionaries in Shane’s Script Library Pack.
The only one I am seeing is Myriad Tables. I did run a script that called MT, and I realized I hadn’t launched the script app on that Mac yet, so I launched it, got the dialog confirming that the three were available, but SD only shows the one in the Dictionary menu.
There is a known problem introduced in 12.3, partly fixed in 12.3.1:
There still appears to be a problem when opening a file via Finder’s open command. e.g. Take a screenshot, then tell Finder to open it:
tell app "Finder" to open file "Screenshot 2022-04-15 at 09.44.59.png" of desktop
If the file hasn’t previously been opened by other means, e.g. by double-clicking on it or by telling another app to open it (e.g. tell app "Preview" to open …), then Finder throws up a permissions error and the open command silently fails. Feel free to file a Finder bug if that affects you. (It’s probably something hokey with Finder and extended attributes.)
Anyway, that’s a specific example of what can go wrong.
…
General observations:
(caution: I am not “IT” so caveat emptor, E&OE, not to be taken as business/technical/legal advice, etc)
If IT are purchasing new Macs, they will come with macOS 12 preinstalled, and chances are they can’t be downgraded to macOS 11. Downgrading to point releases, e.g. 12.3 to 12.2.1, should still be doable. That said, it shouldn’t matter what minor OS version is on a new Mac as IT should already create and maintain full disk images which which to erase and install a complete system setup, including apps, fonts, etc, on all newly purchased and freshly wiped machines.
Your IT department should be 100% responsible for rolling out software updates to Production, not the users. That’s their job. In turn, IT should not be rolling out anything to Production without agreeing a schedule with Production management first. Furthermore, all rollouts should be performed as a series of steps. IT should first update a test machine to check there are no immediate problems, then deploy the update to one or two senior operators’ machines so that those users can give it a full live shakedown, and once they confirm to their own managers that the update hasn’t affected any of their workflows, then Production can give IT the go-ahead to deploy the update to all users.
It should also go without saying that IT should not be rolling out software updates without first having a (tested) rollback strategy in place, so that if a serious problem is found at any time they can quickly revert those machines back to an installation that works.
All of these procedures should be written down in step-by-step detail and signed off by both Production and IT, and strictly followed by both thereafter. Likewise, changes to existing procedures should be agreed by both. If your old IT department didn’t have those procedures in place, work with the new IT department to produce them now. If you are head of Production, you need to work with the head of IT to develop those procedures. And if you are just a Production grunt, you need to take any questions or concerns you have to your Production manager, for them to deal with.
IIRC you are in newspapers, which means you cannot afford downtime due to production machines crapping out. Look up High Availability, make sure you’ve a written SLA in place, and a Business Continuity (DR) Plan as well. Ideally your new IT department should already be well versed in this stuff; if not, your Production management needs to raise it with the managers above them to get those procedures in place.
Good IT is all about risk management, and neither leaving Production machines running ancient out-of-date software without updates for years nor encouraging users to perform their own ad-hoc updates to “latest and greatest” untested software sound like good risk management to me.
Again, if you’re Production manager you should already know this stuff as part of your job, and be involved in on how Production systems are managed by IT. And if you’re not, then it’s your Production manager’s job to deal with this stuff, and to consult you (as the in-house automation specialist) on automation-specific points.
One last thought: considering how important automation is to the business and your importance to the automation, you really should have two Macs on your desk†: one running the existing Production OS version (e.g. 12.2.1) and software, and one running the next version to be tested before deployment (12.3.1). You may even want to keep an extra OS 11.x partition on the older machine as well, in case you need to refer back that far when troubleshooting your scripts.
Again, none of this is professional advice, but I’ve dropped enough “pro” terms that you can Google to learn more yourself. Good luck, and remember: whatever it is, always get it in writing!
–
† I currently have 3 Macs on my desk, one (M1 laptop) for development and two (x86_64 and M1 minis) for testing, with OS partitions from 10.15.7 to 12.3.1. Plus a Win 10 box, as one of my customers is cross-platform too. Honestly, it looks like Starship Enterprise round mine.
The first issue I’ve come across is unstuffing “.sit” files. Our vendor distributes data that way and I’ve been using StuffitExpander to open them.
That’s a little frightening. SIT’s been obsolete for the last 20 years, superseded by industry-standard ZIP.
The permission error dialog you describe sounds like the issue I described, which still occurs in 12.3.1’s Finder. Have your script send the open command to Stuffit Expander, not Finder, and see if that does the trick.
Couple comments: The .sit files have been generated off a mainframe for well over 20 years, and are distributed to various clients. We’ve complained (as have others) but the vendor hasn’t upgraded. (I suspect that who ever wrote the app that exports those files is long gone and they’d have to start over from scratch).
I had been sending the expand command directly to expander, then tried open and then tried open via finder. All failed.
My workaround was to use Unarchiver, which is clunky and opens a useless, irrelevant window when it completes the command, but the script closes that. It’s not ideal but it will work for now.
Other than that I don’t think I’ve experienced the issue you’re mentioning.
Yes, IT is responsible, so my situation is rather unique. IT doesn’t know appleScript from macros. So I’m a “SuperUser.” they provide me a newly imaged Mac, I install software and set it up for the different groups of users that use appleScript, and then they create new images for some users, and update their default image.
At this point I’m testing/configuring images, but I’m also doing this under a time crunch.
At this point I have three. Two running Big Sur, and the new laptop running Monterey.
This is absolutely right. I thought this had been fixed, but I hadn’t fully tested our application, and when it downloads a ZIP for the first time and then tries to extract it, the script fails because of the same permissions bug.
This is because the script just “opened” the ZIP file with Finder, which would then direct Archive Utility to actually do it. Unfortunately, using AppleScript to tell Archive Utility to “open” the file results in Archive Utility displaying the same error instead of Finder.
I am almost worried this permissions issue isn’t a “bug,” but a very crude and heavy-handed security patch that blocks automated processes from wielding the same privileges that a user has (by double-clicking the file in the GUI).
Just tried unzipping with the “unzip” shell command, but that returns a different error message which essentially describes the same thing:
checkdir error: cannot create [folder/file name of whatever is in the ZIP]
Read-only file system
unable to process [same folder/file name]"
It goes on and on, listing an identical error for every file and folder within.
Either this is a ridiculously systemic bug or intentional. This makes me think it’s intentional—the extra detail in the message from the shell about a “read-only filesystem” makes me think macOS could be quarantining the new file, similar to the App Translocation policy.
But that doesn’t explain why they’d do that to something created locally by the user, like a screenshot, which points toward it being a bug.
Thanks, I actually do have it! But this is for a script deployed to a design team, and future teams, and generally they just install the AppleScript applet and have a seamless experience.
I’d rather not build in dependencies to third-party apps they’d then be required to download as an extra step, and of which the availability or functionality is not guaranteed indefinitely.
Not knowing all the technical details of the “macros” are implemented shouldn’t be a problem in itself; that’s why the company hires you. The thing that does matter is that IT knows how important those macros are to business operations (not very/very/critical). If they’re brand new to your company, possibly even to your industry, they might not have been sufficiently briefed on that detail.
If this automation is absolutely critical to daily production (i.e. 5-bells alarms at C-suite level if it ever goes down) then IT should not be sprinting way ahead of you, nor pushing you to half-ass the job of ensuring all that automation will work post-upgrade.
It sounds like you’re already on top of the technical aspects, so the challenge may be more of a logistical and political one. (It’s a common geek weakness: underestimating the value of effective time budgeting and clear immediate communications as the “soft-skill” solutions to superficially technical problems. Speaking from experience.
I’m guessing you’re not in charge of Production, so email your manager (who is) to inform them you don’t have enough hours allocated to complete all the work required of you, and ask them how you should proceed. It is then up to management either to 1. push back on IT to slow down their deployment cycle and give you the time you need; or 2. instruct you to do what you can in the time given. And get that decision confirmed in writing too, so you’ve fully CYA. Either way, management is kept appraised of any issues you have, and their decision and any consequences arising is on them, not you.
That would be my first instinct. Trying to retrofit modern security systems onto a half-century old OS is probably the textbook definition of “unintended consequences”. No easy answers for anyone, Apple included.
All you can do is write up instructions for replicating the problem in 12.3.1 and file a Radar ticket (or Feedback Assistant as it’s now called), and hope someone at Apple takes notice. I had a quick look on OpenRadar to see if someone had already written a ticket you could copy-paste into a duplicate report, but nothing jumped out:
If you do file a Radar ticket on this issue, post it to OpenRadar as well and ask folks here to submit duplicates of that ticket to Radar. (Apple will close them again as duplicates; however, the more folk are affected, they more likely they are to do something about it.)
I’m not sure if this will work with .sit files but we’ve been using the “unzip” and “ditto” commands for unpacking our ZIP files. I’ve been using Monterey for a few months now and haven’t had many issues since updating. The v12.3.1 update also did fix the Finder open command for us.
Example of the unzip call we’re making:
do shell script "unzip -uo " & quoted form of the POSIX path of sourceZip & " -d " & quoted form of the POSIX path of destinationFolder
Example ditto call we’re making:
do shell script "ditto -x -k " & quoted form of the POSIX path of sourceZip & space & quoted form of the POSIX path of destinationFolder
Off-hand I can’t remember what cases we’re using unzip vs ditto but there was a reason for it. The unfortunate thing with unzip is that it leaves behind an empty “__MACOSX” folder.
