[SOLVED] Can't use wildcard in path for FF user.js script

About writing shell scripts and making the most of your shell
Forum rules
Topics in this forum are automatically closed 6 months after creation.
Locked
User avatar
majpooper
Level 8
Level 8
Posts: 2084
Joined: Thu May 09, 2013 1:56 pm
Location: North Carolina, USA

[SOLVED] Can't use wildcard in path for FF user.js script

Post by majpooper »

I am putting together a series of installation scripts to make life a bit easier because I am a lazy slug. these scripts will be added to one large script. One of them is to set Firefox about:config preferences based on Pjotr's Easy Linux Tips plus a few others. The problem is the path to the user.js file will contain a unique user name and placed in a xxxx.default-release file where the xxxx is also unique for each instance therefore I am trying to use wildcards in the path to create the usr.js file and then to add content. I have researched this and there are examples that indicate that this should work. Am I over looking something obvious?

Example:
/home/*/.bashrc will match all .bashrc files in all user's home directories.
/home/*/.ssh/**/*.key will match all files ending in .key in all user's .ssh directories in all user's home directories.
Here is the script:

Code: Select all

#!/bin/bash
# Set Firefox preferences in about:config
touch /home/*/.mozilla/firefox/*.default-release/user.js
bash -c "echo '//Firefox about:config settings
user_pref("widget.non-native-theme.scrollbar.size.override", 20);
user_pref("widget.non-native-theme.scrollbar.size.override", .85);
user_pref("widget.non-native-theme.gtk.scrollbar.allow-buttons", true);
user_pref("widget.non-native-theme.gtk.scrollbar.round-thumb", true);
user_pref("browser.cache.disk.enable", false);
user_pref("browser.cache.memory.enable", true);
user_pref("browser.cache.memory.capacity", 1048576);
user_pref("browser.sessionstore.interval", 15000000);
user_pref("dom.webnotifications.enabled", false);
user_pref("browser.urlbar.maxRichResults", 0);' >> /home/*/.mozilla/firefox/*.default-release/user.js"
exit
Here is the output when run:

Code: Select all

root@lmde4:/home/gorilla# ./ff-user.sh
touch: cannot touch '/home/*/.mozilla/firefox/*.default-release/user.js': No such file or directory
bash: line 10: /home/boogers/.mozilla/firefox/*.default-release/user.js: No such file or directory
Last edited by LockBot on Wed Dec 28, 2022 7:16 am, edited 2 times in total.
Reason: Topic automatically closed 6 months after creation. New replies are no longer allowed.
LittleScriptMan
Level 3
Level 3
Posts: 158
Joined: Thu Jan 13, 2022 8:42 am

Re: Can't use wildcard in path for FF user.js script

Post by LittleScriptMan »

Some thoughts about this :
- What would be the problem with environment variables as $USER or $HOME instead of wildcards ? Using cat command to test :

Code: Select all

 cat $HOME/.bashrc
will display the .bashrc of the current user whoever he is and

Code: Select all

cat $HOME/.mozilla/firefox/default-release/user.js
will display the user.js of default-release if such a profile exists.

Completely different, I can't seize the logic behind :
majpooper wrote: Fri Jan 21, 2022 3:35 pm user_pref("browser.sessionstore.interval", 15000000);
which means allow a sessionstore then wait about 42 hours (150000000 milliseconds precisely) for the next one.
Wouldn't it be much simpler just setting :

Code: Select all

user_pref("browser.sessionstore.enabled", false);
keeping the possibility one day to set it to true again and reestablishing default values without needing to remember if you tweaked the interval, the tabs, the privacy level...
The browser.sessionstore.enabled pref is the master switch and all the other browser.sessionstore values are never taken in account when set to false.
Last edited by karlchen on Fri Jan 21, 2022 5:38 pm, edited 1 time in total.
Reason: Removed the no longer needed full quote of the post right above this one
Interests : Firefox, Cinnamon & Bash Scripts
LM Version : LMDE5 (LMDE4 just in case)
User avatar
majpooper
Level 8
Level 8
Posts: 2084
Joined: Thu May 09, 2013 1:56 pm
Location: North Carolina, USA

Re: Can't use wildcard in path for FF user.js script

Post by majpooper »

Not sure I follow
But here is the output from both systems I am using for test
LMDE 4

Code: Select all

root@lmde4:/home/gorilla/.mozilla/firefox# ls
'Crash Reports'   installs.ini	'Pending Pings'   profiles.ini	 vbae11eb.default-release   ynykblrf.default
LM 20.3 Cinnamon

Code: Select all

oot@lm20:/home/boogers/.mozilla/firefox# ls
 5t8xohti.default  'Crash Reports'   fdutjq0f.default-release   installs.ini  'Pending Pings'   profiles.ini

As you can see in both there are two *.default dir one with the -release appended which is the one that contains the FF profile. The other is the one that has just one file i.e. times.json. I know *.default-release is where the user.js should go because first about:support identifys it as such and secondly if I manually add user.js there with the content I have chosen it works. So I know where the user.js file needs to go I just don't know how to get around the unique identifiers of user and that prefix of the default-release file.

Here are the systems I am testing on -LMDE 4 and LM 20.3

Code: Select all

System:    Host: lmde4 Kernel: 4.19.0-18-amd64 x86_64 bits: 64 Console: tty 0 Distro: LMDE 4 Debbie 
Machine:   Type: Virtualbox System: innotek product: VirtualBox v: 1.2 serial: N/A 
           Mobo: Oracle model: VirtualBox v: 1.2 serial: N/A BIOS: innotek v: VirtualBox date: 12/01/2006 

Code: Select all

System:    Host: lm20 Kernel: 5.4.0-96-generic x86_64 bits: 64 compiler: gcc v: 9.3.0 Console: tty 1 
           Distro: Linux Mint 20.3 Una base: Ubuntu 20.04 focal 
Machine:   Type: Desktop System: Hewlett-Packard product: 310-1124f v: xxx0204GRxxxxxxxx0 serial: 4CS117097R 
           Mobo: Hewlett-Packard model: 2AAC serial: N/A BIOS: American Megatrends v: 6.06 date: 03/22/2011 
EDIT: OK bringing up running it as root is a good consideration - the reasoning was testing it like it will run as part of a bigger script that has to run as root to get around password for sudo - I suppose I could temporarily fix that in sudoers just to run the bigger script then fix it back after.
User avatar
karlchen
Level 23
Level 23
Posts: 18173
Joined: Sat Dec 31, 2011 7:21 am
Location: Germany

Re: Can't use wildcard in path for FF user.js script

Post by karlchen »

Hello, majpooper.

In your case all the Firefox userprofile directories seem to match your search pattern *.default-release. So the pattern is ok in your case.

Why your touch command touch /home/*/.mozilla/firefox/*.default-release/user.js fails:

Code: Select all

karl@unimatrix3:~/Downloads/temp$ mkdir 1 2 3
karl@unimatrix3:~/Downloads/temp$ touch ./*/user.js
touch: cannot touch './*/user.js': No such file or directory
The touch command does not permit wildcards in the given pathname.
The expectation is touch cycles through the 3 directories named 1, 2 and 3 and creates the files
./1/user.js
./2/user.js
./3/user.js

But it does not do so. Instead it displays the well-known error message and exits.

Why the output redirection at the end (line 10) >> /home/*/.mozilla/firefox/*.default-release/user.js fails:
For the same reason as touch.

Both commands are ambiguous.

Regards,
Karl
Image
The people of Alderaan have been bravely fighting back the clone warriors sent out by the unscrupulous Sith Lord Palpatine for 762 days now.
Lifeline
User avatar
karlchen
Level 23
Level 23
Posts: 18173
Joined: Sat Dec 31, 2011 7:21 am
Location: Germany

Re: Can't use wildcard in path for FF user.js script

Post by karlchen »

Hello, majpooper.

Seeing this commandline of yours, root@lmde4:/home/gorilla# ./ff-user.sh, I would like to point out an upside and a downside of running the script ff-user.sh with root permissions:

Upside
root will be able to read any file and directory, irrespecitve of its ownership owner:group, and irrspective of the access permissions -rwx------ e.g.
root will also be able to create any file, provided the commandline syntax is correct. (see post above)

Downside
Your script is meant to create user.js files in the users' Firefox userprofile's directories.
In case the files do not exist, yet, ff-user.sh executed with root permissions will create the files, owned by root:root, instead of owned by user:usergroup.
In order to correct that, the script would have to use chown in order give away the file to the respective users.

Regards,
Karl
Image
The people of Alderaan have been bravely fighting back the clone warriors sent out by the unscrupulous Sith Lord Palpatine for 762 days now.
Lifeline
User avatar
majpooper
Level 8
Level 8
Posts: 2084
Joined: Thu May 09, 2013 1:56 pm
Location: North Carolina, USA

Re: Can't use wildcard in path for FF user.js script

Post by majpooper »

LittleScriptMan wrote: Fri Jan 21, 2022 4:50 pm Completely different, I can't seize the logic behind :
majpooper wrote: Fri Jan 21, 2022 3:35 pm user_pref("browser.sessionstore.interval", 15000000);
which means allow a sessionstore then wait about 42 hours (150000000 milliseconds precisely) for the next one.
Wouldn't it be much simpler just setting :

Code: Select all

user_pref("browser.sessionstore.enabled", false);
keeping the possibility one day to set it to true again and reestablishing default values without needing to remember if you tweaked the interval, the tabs, the privacy level...
The browser.sessionstore.enabled pref is the master switch and all the other browser.sessionstore values are never taken in account when set to false.
Good Catch - this is a mistake - the 150000000 value is meant for a different prev.

Code: Select all

user_pref("browser.sessionstore.interval", 15000000);
I can fix that

$USER works for the user but I will have to figure out the how to get around the touch command as karlchen points out as well as running as root.
User avatar
majpooper
Level 8
Level 8
Posts: 2084
Joined: Thu May 09, 2013 1:56 pm
Location: North Carolina, USA

Re: Can't use wildcard in path for FF user.js script

Post by majpooper »

majpooper wrote: Fri Jan 21, 2022 6:00 pm
LittleScriptMan wrote: Fri Jan 21, 2022 4:50 pm Completely different, I can't seize the logic behind :
majpooper wrote: Fri Jan 21, 2022 3:35 pm user_pref("browser.sessionstore.interval", 15000000);
which means allow a sessionstore then wait about 42 hours (150000000 milliseconds precisely) for the next one.
Wouldn't it be much simpler just setting :

Code: Select all

user_pref("browser.sessionstore.enabled", false);
keeping the possibility one day to set it to true again and reestablishing default values without needing to remember if you tweaked the interval, the tabs, the privacy level...
The browser.sessionstore.enabled pref is the master switch and all the other browser.sessionstore values are never taken in account when set to false.
Good Catch - this is a mistake - the 150000000 value is meant for a different prev.

Code: Select all

user_pref("browser.sessionstore.interval", 15000000);
I can fix that

$USER works for the user but I will have to figure out the how to get around the touch command as karlchen points out as well as running as root.
EDIT: I think I am just going to drop this for now - it is simpler to just to create the user.js and cut&paste the contents.
Also running the script as root is ill-advised.

Mods if you want to delete this thread it is OK with me probably a good idea.
rene
Level 20
Level 20
Posts: 12240
Joined: Sun Mar 27, 2016 6:58 pm

Re: Can't use wildcard in path for FF user.js script

Post by rene »

The reason the wildcard approach doesn't work in this case is due to the user.js file(s) not pre-existing: wildcards expand only into actual matches. You can use a find -exec or, better given that you also want to keep the user.js inside of your script, a simple for loop. I.e., with the user.js as from your original post,

Code: Select all

#!/bin/bash
#
# Set Firefox preferences in about:config

shopt -s nullglob

for profile in /home/*/.mozilla/firefox/*.default-release/; do
	cat >>${profile}user.js <<EOF
//Firefox about:config settings
user_pref("widget.non-native-theme.scrollbar.size.override", 20);
user_pref("widget.non-native-theme.scrollbar.size.override", .85);
user_pref("widget.non-native-theme.gtk.scrollbar.allow-buttons", true);
user_pref("widget.non-native-theme.gtk.scrollbar.round-thumb", true);
user_pref("browser.cache.disk.enable", false);
user_pref("browser.cache.memory.enable", true);
user_pref("browser.cache.memory.capacity", 1048576);
user_pref("browser.sessionstore.interval", 15000000);
user_pref("dom.webnotifications.enabled", false);
user_pref("browser.urlbar.maxRichResults", 0);
EOF
	chown --reference ${profile} ${profile}user.js
done
This uses a so-called here-document rather than your echo which is somewhat nicer, but note that only the for loop approach is functionally important (and the shopt only has bash not complain when no directories /home/*/.mozilla/firefox/*.default-release yet exist).

The thing karlchen said as to root/user when running with sudo is foregone by the chown grabbing credentials from the profile directory itself.

[EDIT] Note; edited twice after posting; first to use chown --reference rather than stat, second to have said reference be the profile directories itself rather than the home directories.
User avatar
majpooper
Level 8
Level 8
Posts: 2084
Joined: Thu May 09, 2013 1:56 pm
Location: North Carolina, USA

Re: Can't use wildcard in path for FF user.js script

Post by majpooper »

THX much rene - you have bailed me out yet again - the reality is you wrote the script for me.
I have been looking over what you did and googleing the commands and researching to try and understand how the script works - hopefully it will help me progress just a bit more in writing shell scripts. I am writing smaller single function scripts as they are easier to test that way rather than one big script.

The one glitch - that I can deal with - is for the script to actually work i.e. load the user.js file Firefox has to be open - easy enough - got that working. However that means the script needs to be invoked from the user not root.
Of course this will mean my master install script will have to be invoked from the user as well. Probably not all that elegant but I think I can use

Code: Select all

sed -i 
in the master script to edit sudoers to run sudo without a password then at the end of the script set sudoers back. Working on how to get prompted for the password

I don't drink but if you ever get to NC - beers on me - we have some pretty nice breweries here and great BBQ (don't listen to what the folks from Texas say).

Again, thank you
Last edited by majpooper on Sun Jan 23, 2022 11:33 am, edited 1 time in total.
rene
Level 20
Level 20
Posts: 12240
Joined: Sun Mar 27, 2016 6:58 pm

Re: Can't use wildcard in path for FF user.js script

Post by rene »

majpooper wrote: Sun Jan 23, 2022 12:32 am [ ... ] for the script to actually work i.e. load the user.js file Firefox has to be open
This seems to not be the case here. The way that user.js should apparently work and does at the moment here is that on startup of Firefox any in it found valid preferences are copied to prefs.js -- which is also to say you can with a user.js present no longer consistently edit preferences via about:config which for a bit interfered with my understanding/testing at least. But Works For Me in that sense.

Of course, some /home/*/.mozilla/firefox/*.default-release profile directory has to pre-exist lest the loop loops over nothing; is that what you are seeing? If you are e.g. running this before Firefox was even ever once started by/for a given user then, yes, not even said user's /home/*/.mozilla itself exists, and any script would have no possibility to know where to place that user.js file so to have it used by a future profile. Confused, that is...

Anyways: if you're done with this, all fine, but not fully grasping the situation...
User avatar
majpooper
Level 8
Level 8
Posts: 2084
Joined: Thu May 09, 2013 1:56 pm
Location: North Carolina, USA

Re: [SOLVED] Can't use wildcard in path for FF user.js script

Post by majpooper »

Just a quick back ground. I am trying to make a series of scripts that I will compile into what I refer to as the master install script. This script, a compilation of several smaller scripts will remove some packages add a few adjust some settings per Pjotr's web site like delete the suspend and hibernate button and so on.

So yes when I run the script to load user.js firefox will have not been started for the first time. For testing I have

Code: Select all

sudo apt purge firefox
then

Code: Select all

sudo apt install -y firefox
before testing the script. Without launching firefox for the first time a look in /home/user reveals there is not a .mozilla dir. If one tries to run the script at that point it of course will not work. However upon executing

Code: Select all

firefox &>/dev/null & disown 
prior to running the script firefox launches establishes /home/user/.mozilla and consequently a dir in which to load user.js. Evidently there is a bug known to mozilla that causes some erroneous output when starting firefox from the terminal the command syntax above eliminates it.

For the setting in user.js to take effect firefox must be re-booted - for me that is not a problem or a concern as part of the installation - firefox will be rebooted in any case.

The last thing - the about:config settings seem to be persistent once set however user.js it would seem is checked each time firefox is launched because simply making a change in user.js will take effect the next time firefox is launched. Anyway that is the impression - I will have to test that theory but that so far has been my observation.

What is confusing me now however is editing sudoers. I thought to make the change active in sudoers I would have to reboot the system but that is not happening on my test rig. I execute

Code: Select all

sudo sed -i '26s/.*/%sudo   ALL=(ALL:ALL) NOPASSWD:ALL/' /etc/sudoers
enter the user password and all the other sudo in all my scripts run. At the end of the master script I will delete NOPASSWD: and reboot the system. But that surprised me.

EDIT: OK it seems like editing sudoers is not necessary. I never noticed this before but after entering the user password for sudo for the first instance the user password is not requested for subsequent instances of sudo. That does not seem right to me.

EDIT 2:
rene wrote: Sun Jan 23, 2022 2:53 am
majpooper wrote: Sun Jan 23, 2022 12:32 am [ ... ] for the script to actually work i.e. load the user.js file Firefox has to be open
This seems to not be the case here.
My comment here is misleading - firefox has to have been launched at least once - I suppose it could then be closed once .mozilla is created and the script would still run.
rene
Level 20
Level 20
Posts: 12240
Joined: Sun Mar 27, 2016 6:58 pm

Re: [SOLVED] Can't use wildcard in path for FF user.js script

Post by rene »

Changing /etc/sudoers does not require a reboot indeed; it's a configuration file for the command sudo; is read anew each time said command is invoked.

The "no password second time time around" thing is sudo's caching behaviour; see timestamp_timeout in man sudoers (although admittedly one of the worst manpages imaginable...). Default is 15 minutes.

However; if I were you I'd not muck about with /etc/sudoers in the first place. Making system-wide changes is exactly the kind of thing root rather than a user should be doing: really nothing wrong with running the script itself via sudo as long as you're careful and e.g. chown files back to the user as per previous.
User avatar
majpooper
Level 8
Level 8
Posts: 2084
Joined: Thu May 09, 2013 1:56 pm
Location: North Carolina, USA

Re: [SOLVED] Can't use wildcard in path for FF user.js script

Post by majpooper »

THX again rene
rene wrote: Sun Jan 23, 2022 1:23 pm Changing /etc/sudoers does not require a reboot indeed; it's a configuration file for the command sudo; is read anew each time said command is invoked.

The "no password second time time around" thing is sudo's caching behaviour; see timestamp_timeout in man sudoers (although admittedly one of the worst manpages imaginable...). Default is 15 minutes.
I will have to time the entire install script - I can envision it taking longer than 15 minutes. I will try running it without making any edits to sudoers. It is purging and installing software packages and then updating that can take time especially the kernel updates.
rene wrote: Sun Jan 23, 2022 1:23 pm However; if I were you I'd not muck about with /etc/sudoers in the first place. Making system-wide changes is exactly the kind of thing root rather than a user should be doing: really nothing wrong with running the script itself via sudo as long as you're careful and e.g. chown files back to the user as per previous.
Good advice indeed
Locked

Return to “Scripts & Bash”