http://www.perlmonks.org?node_id=11160718

hepcat72 has asked for the wisdom of the Perl Monks concerning the following question:

This is a cross-post from stackexchange, so apologies for that. Given the initial response there, I thought this may be a better place to, but if you would like to see my screenshots, they are in that stack post.

I updated my mac mini (that is a part of my entertainment center) to Sonoma the other day. It was long overdue. I think it was still on High Sierra before. I have a Node-RED instance on that computer (also lagging behind on updates at version v1.2.7, but I suspect that this is unrelated to the version - and it would be nice if someone with the latest version could run my MRE and confirm it's an issue in the latest NR...).

My script that identifies the correct sqlite file of the Reminders app database (as well as other scripts that do similar things) no longer works correctly after the update. I have boiled down the problem with differing behaviors of the bsd_glob subroutine that is a part of the File::Glob ':glob' perl module.

The thing is, it works as expected on the command line (even when called from other scripts (like Apple Scripts and SLURM scripts I call it from at work)). But after the update to Sonoma, it no longer behaves the same from the Node-RED exec node, which returns no file matches.

Here is an MRE example, run from...

The command line **returns 3 files**:

[golrath:~] robleach% perl -e 'use File::Glob ":glob";print(bsd_glob("
+/Users/robleach/Library/Group Containers/group.com.apple.reminders/Co
+ntainer_v1/Stores/Data-*-*.sqlite",GLOB_CSH),"\n")'
/Users/robleach/Library/Group Containers/group.com.apple.reminders/Con
+tainer_v1/Stores/Data-A0D24954-1339-494B-9E7D-9D0911C096F8.sqlite/Use
+rs/robleach/Library/Group Containers/group.com.apple.reminders/Contai
+ner_v1/Stores/Data-B826F8F1-0153-4318-8666-F1C8EBBFCE96.sqlite/Users/
+robleach/Library/Group Containers/group.com.apple.reminders/Container
+_v1/Stores/Data-D8328338-F382-4E34-8C39-E1DC35D60A32.sqlite

[download]

And via a Node-RED exec node, **it returns 0 files**.

My first thought was that the perl executable, module, or even csh versions must have differed, but I confirmed they're all the same between the command line and Node-RED.

The only difference is the perl soft-link in the path. Could that be what's causing the difference in behavior? I can't imagine how it could...

Replies are listed 'Best First'.
Re: Weird differing bsd_glob behavior
by Corion (Patriarch) on Jul 23, 2024 at 16:48 UTC

    My random wild guess would be file/directory permissions. Maybe the user that Node-RED runs under does not have permissions to list files under one of the parent directories in the path given?

[reply]
      Someone on stack had a similar hunch. Seems promising. MacOS has gotten more and more proactive about security and permissions... However, I just checked and the entire path to that file (including the file) is owned by me and in my group, with read permissions throughout - and the node-red process is running as me. Unless Apple is doing something funky... which I don't put past them at all.
[reply]

        Me :)

        What's the output of 

        perl -e'stat("/Users/robleach/Library/Group Containers/group.com.apple
+.reminders/Container_v1/Stores") or die "stat: $!\n"; print "ok\n";'

        [download]

        Update: Ah, you already said on SO that ls fails with Operation not permitted. This will do the same, and confirm a permission problem.

[reply]
[d/l]
[select]
[reply]
Re: Weird differing bsd_glob behavior
by Anonymous Monk on Jul 26, 2024 at 05:01 UTC
    (iirc) for dirs with wildcard matching, you ALSO need 'x' ie 'search' perms in the dir's perms list.
[reply]

Back to Seekers of Perl Wisdom