I am trying to create a one-liner in bash | aftersetup

I try to create a one-liner in Bash for the command below. If I can call just this one-liner as sh in the bash script it is also good.
It looks like that it is in sh.

The command below creates a file in profile.d and adds the view lines as a function.
With everything I tried I get syntax errors.

sudo tee /etc/profile.d/custom.sh << "EOF"
dnf() {
sudo dnf "${@}"
}
EOF
. /etc/profile

Source: Can make DNF cache system wide instead of per user? - #2 by vgaetera

Would be grateful for a pair of eyes which could help me :wink:

1 Like

The command works for me exactly as posted.

What syntax error are you getting and when?

You can do this with an alias in your .bashrc

alias dnf="sudo dnf"
2 Likes

I not need it exactly as is. I want to have it in one line. And call it in a bash script, if the instructions are in sh, this needs to be taken in consideration.

System wide, not just for a user.

Are you asking for us to translate the code from BASH to posix SH?

Is something like this what you are looking for?:

sudo dd of=/etc/profile.d/custom.sh status=none <<< 'function dnf { sudo /usr/bin/dnf "${@}"; }'

The alias that Barry suggested would be the better way to do that.

Or

echo 'function dnf { sudo dnf "${@}"; }' | sudo cp /dev/stdin /etc/profile.d/custom.sh

There are 101 ways to skin this cat…

2 Likes

If you want to import the function definition at the same time…

. <(sudo tee /etc/profile.d/custom.sh <<< 'function dnf { sudo /usr/bin/dnf "${@}"; }')

Be sure to use /usr/bin/dnf in the function definition to avoid a recursion loop. :slightly_smiling_face:

The alias Barry suggested earlier is still the better way.

3 Likes

Thanks a lot for your help folks.

I am writing a bash script to automate the config after a new installation. For the moment just for the Gnome Desktop.
Now it works as it should. The example below shows why I liked a one liner.

#!/bin/bash
# ilikelinux@fedoraproject.org
##  Aftersetup configuration Fedora Linux / Gnome Desktop | 2025-12-10; 09:45:48 | https://fedoraproject.org/wiki/User:ilikelinux
#===============================================================================================================================>
# usage: yes_or_no "${normal}Installing ...$"  &&  echo "${green}do something "

#functions & vareiables
# colors
normal=`echo -en "\e[m"`
orange=`echo -en "\e[33m"`
yellow=`echo -en "\e[93m"`
red=`echo -en "\e[31m"`
green=`echo -en "\e[32m"`

function yes_or_no {
    while true; do
        read -p "$* ?  [y/n]: " yn
        case $yn in
            [Yy]*) return 0  ;;
            [Nn]*) printf  "\n ${red}Job Aborted ... \n" ; return  1 ;;
        esac
    done
}

# Allways sudo for dnf:
echo -e "\n${yellow} Use allways sudo for DNF: "
yes_or_no " ${normal}Installing ...$"  &&  echo " ${green}Allways use sudo for DNF script installed ${normal}  " &&  echo 'function dnf { sudo /usr/bin/dnf "${@}"; }' | sudo cp /dev/stdin /etc/profile.d/allways_sudo-dnf.sh
1 Like

FYI: Technically the 0 is not needed, 0 is assume if you omit a param.
The use of 0 is cargo culted these days.

1 Like

Here my set of changes I do after a setup:

Grateful for feedback …

2 Likes

It’s an interesting take on the problem. “The problem” being what to do on a new system and how to do it. It goes like this:

  1. You have this script that you get onto the new host somehow.
  2. Then you run it.
  3. Time passes and you tweak your script. Now your script and prior hosts are out of sync.
  4. Goto step #1 × however many hosts you’re maintaining.

Alternatively, you can have your initial setup script configure a dedicated Ansible user with a public key and password-less sudo. Then manage all the other configuration on your entire fleet through Ansible. Tweak a config? Run your Ansible playbook(s) once targeting your entire host inventory, and all your hosts are synced up again. Each Ansible task could be one of your one-liners, and you could add other more canonical Ansible tasks as well.

But what you have is an excellent start! It’s amazing how many little tweaks creep in, and how quickly config drift across hosts starts to impact getting things done. What you’re doing with this script is so much better than trying to update these things manually, especially once multiple hosts are involved.

However, I think your one-liner pattern is already causing readability and maintainability issues. Compare for example this:

yes_or_no " ${normal}Installing ...$"  &&  echo " ${green}Make Keyboard Changes ${normal}  " && localectl set-locale LANG=en_US.UTF-8 LC_NUMERIC=pt_BR.UTF-8 LC_TIME=pt_BR.UTF-8 LC_MONETARY=pt_BR.UTF-8 LC_PAPER=pt_BR.UTF-8 LC_MEASUREMENT=pt_BR.UTF-8  && localectl set-x11-keymap us && gsettings set org.gnome.desktop.input-sources xkb-options "['lv3:ralt_atl', 'compose:prsc', 'kpdl:dot']"

to this:

yes_or_no " ${normal}Installing ...$"  &&  {
    echo " ${green}Make Keyboard Changes ${normal}  "
    localectl set-locale LANG=en_US.UTF-8 \
                         LC_NUMERIC=pt_BR.UTF-8 \
                         LC_TIME=pt_BR.UTF-8 \
                         LC_MONETARY=pt_BR.UTF-8 \
                         LC_PAPER=pt_BR.UTF-8 \
                         LC_MEASUREMENT=pt_BR.UTF-8
    localectl set-x11-keymap us
    gsettings set org.gnome.desktop.input-sources xkb-options "['lv3:ralt_atl', 'compose:prsc', 'kpdl:dot']"
}

This and a few other changes are in a pull request I’ve sent to your project.

2 Likes

Thanks for reading thru the script.

I was looking into Ansible once, however to keep up with that, for that what I need it for, is to much. So a bash script for my use case is more as enough.

I will have a look to the pull request when I do have a bit more time.
Thanks so far.