0

Writing a quick bash function to change the network TTL (for tethering from a phone,) but as it turns out, it's a slightly different command for each system so to accomodate the logic, my simple script grew many more lines. This is it minus non-essentials:

#!/usr/bin/env sh
chttl(){
    set -e
    felicia() {
        #prints error messages;
    }
    trap 'felicia 3' INT
    trap 'felicia 1' HUP QUIT ABRT TERM
    chttlhelp(){
        #prints help, link to newer copy, wiki;
    }
    chttldo(){
        if [ "$(uname)" = Darwin ]; then
            sysctl net.inet.ip.ttl="${1:-65}"
        elif [ "$(uname)" = Linux ] ; then
            sysctl -w net.ipv4.ip_default_ttl="${1:-65}"
        elif [ "$(uname)" = FreeBSD ] ; then
            sysctl net.inet.ip.ttl="${1:-65}"
        elif uname | grep -i "bsd"; then
            #prints some pointers, but does nothing.
        else
            #prints some info about why it does nothing.
        fi
    }
    case "$1" in
        -h|--help|-?) chttlhelp ;;
        *) chttldo "$1" ;;
    esac
}
chttl "$1"

Because I had to test it somehow, first I turned the function into a script. And then because I'm targeting different OSes, I'd thought it might be a good idea to switch to sh rather than bash to attempt to make it POSIX-compliant. I've never not used bash before, I don't know the differences between it and the Bourne Shell, but I figured I should be able to figure something out with my ShellCheck-assisted IDE.

And for what it's worth, in macOS it worked fine. In Linux (Fedora 40+) I get this:

[Fri29@18:03:16][sv@vterminal:~] $〉chttl
sysctl: permission denied on key "net.ipv4.ip_default_ttl"
[Fri29@18:03:19][sv@vterminal:~] $〉sudo chttl
sudo: chttl: command not found
[Fri29@18:03:25][sv@vterminal:~] $〉sudo -s
[Fri29@18:03:29][root@vterminal:/home/senseivita] #〉chttl
bash: chttl: command not found

The script is called chttl too, as the title indicates. It's in the ~/bin which is on my $PATH which syncs across systems (paths ~/{.ssh,.bash_profile,.bashrc,bin} are synced)...-- Wait. Could that be it?? (Sorry, I'm thinking as I type.)

It changes interpreter so maybe it needs new PATH too?? The PATH for specific for bash, I mean... the files have the actual "bash" word in them. Could it be inherited by chance when it switches to sh?? It makes more sense the more I think about it but I don't know about cross-interpreter environment inheritance, or whatever it's called. I'm also realizing the I haven't even checked is set -e at the very beginning does something in sh, or have any idea of how to set the PATH for sh either.

Though, at the same time, I'm seeing that when I elevate myself, the error says bash: chttl: command not found not sh command some-some...

Could you give me a little advice please?

UPDATE

I checked my other scripts (all bash though, as I mentioned earlier) and I saw that I've used the same name for the main function for the script itself and not once but in a ton of them, I wasn't imagining it. I guess what I'm saying is that it really changed nothing, I'm still confused (2x). "confused plus pro max" -- sounds flashier.

There's one solution I think would work; adding sudo to the sysctl command in the script itself, but I don't think that should be my call but the person's using the script -- even if that person is myself. I'm not a dev so I don't know about proper script etiquette. It doesn't feel right, though. Some advice?

Improve this question
1

2 Answers 2

Reset to default
0

What you name main function is actually ordinary function. There is no such thing as "main function" in bash. In C you have main but in bash you do not, the script itself is the "main function".

About the problem with run: always run such programs/scrips by full path:

sudo /path/to/chttl

And for better readability maybe will be good to add "extension" to give you visual info this is script like chttl.sh

Improve this answer
8
  • 2
    No system scripts have an extension - they are just programs to be executed. Why create an unnecessary .sh suffix? Commented Jan 11 at 18:22
  • 2
    @ChrisDavies, readability. About system scripts please do not hold me responsible for someones not wise design. :) BTW can you tell me why someone will use unnecessary dash in program name? (subscription-manager for example) Commented Jan 11 at 18:47
  • 2
    @ChrisDavies The name of an executable is largely arbitrary, so adding .sh to the end of it doesn't really matter. There is no technical benefit, but there is also no disadvantage. Commented Jan 11 at 19:04
  • I believe such extra characters are recommended to ease reading by non-native English readers. But since I am a native English reader I cannot give an authoritative answer Commented Jan 11 at 19:05
  • @Kusalananda there is technical disadvantage if someone wants to rewrite the application in a different language. Would you accept a python script ending in .pl (Perl)? Commented Jan 11 at 19:06
0

The reason for the sudo: chttl: command not found message is that the user ~/bin directory is not in the sudo path.

The reason for bash: chttl: command not found (instead of the sh message you expect) is that sudo -s runs a bash instance. This bash cannot find a command chttl so the script is never run, the shebang line #!/usr/bin/env sh never executed.

As already mentioned in the first answer: The solution is to use sudo with the full script path.

Improve this answer

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.