

:motions at trillions of times people that signed up for Fb, Ig, Twit, TkTk, etc/everything without reading the Terms of Service:
:motions at trillions of times people that signed up for Fb, Ig, Twit, TkTk, etc/everything without reading the Terms of Service:
Ok, just be sure it has an integrated circuit breaker otherwise its just…a surge protector. You’ll also need to identify what load it triggers at. For example, I use these on my gear https://tripplite.eaton.com/isobar-4-outlet-surge-protector-6-ft-cord-3300-joules-diagnostic-leds~ISOBAR4ULTRA and they’re rated to 12A which should protect a 15A rated smart plug. I put rated in italics because errrryone is buying CE (instead of UL listed) smart plugs.
Place a surge protector between the smart plug and the PC to be safe.
What benefit does this serve in this situation?
shows your internal IP
nearly everyone uses 192.168.1.1 for their local-non-enterprise network
Verizon as an ISP
You missed BLTMND = Baltimore Maryland, this is the only thing that is identifying but if Bmore is large metropolitan area so youve narrowed it down to ~million people
edge server is hosting your connection
shows their gateway not whatever you just said
your external IP
no it doesnt.
/edit carriage returns
Neither ~/bin or ~/.local/bin are part of most shell’s default
$PATH
so you’re going to have to modify the user’s shell profile (or rc) to include it. It’s possible that your favorite distro includes it but not mine. For example(s): unset PATH /bin/bash --noprofile --norc bash-5.2$ echo $PATH /usr/local/bin:/usr/bin
or
unset PATH /bin/zsh --no-rcs --no-global-rcs Sinthesis% echo $PATH /bin:/usr/bin:/usr/ucb:/usr/local/bin ls -l /bin lrwxrwxrwx. 1 root root 7 Jan 23 2024 /bin -> usr/bin
That was on Fedora. The funny thing is /bin is soft linked to usr/bin, weeeee.
This is on Debian
Sinthesis@debian:~$ /bin/bash --noprofile --norc bash-5.2$ echo $PATH /usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/bin:/sbin:.
I’m not sure why you’re bringing the XDG or systemd “standard” into this. POSIX standard would be more appropriate but they don’t say anything on the matter, nor should they really. The most important thing is, be predictable. If the user has a problem with one of your scripts, what do they do first?
which wolf_bin
will show them the full path to the script. So really, the location does not matter much.That said I would go with one of these two options:
Make a package for your distro. This may be overkill for a couple scripts but you did say they’re in a git repository so you could automate it. The package would install to /usr/bin which would require sudo or root. If the scripts are only allowed to be run by one user, set the rwx and group permissions.
A pattern I like, especially for lightweight things such as scripts that don’t require compiling or OS management and also are using git; a “hidden” or “dot” directory in the user’s home where the repo lives e.g.
~/.lemmywolf/
Then add scripts directory to the user’s $PATH e.g.PATH=$PATH:~/.lemmywolf/scripts
. This is what some fairly large projects like pyenv or volta do. You could take it a step farther and modify this installer script to your liking https://github.com/pyenv/pyenv-installer/blob/master/bin/pyenv-installer/edit 20 year Linux user (Redhat AS2.1) and 5 years of Unix (HPUX & Solaris) before that.
/edit2 I just noticed the pyenv-installer does not modify the user’s shell profile. That could easily be added to the script though.