0

I need advice on how to make every command I run in a Bash script first display itself and then execute. I created a simple function and a subsequent sed command to uncomment lines in the pacman.conf file, but it isn't working. Specifically, I want to uncomment these two lines:

YC="\033[1;33m"
RC="\033[0m"

RCH() {
    echo -e "${YC}    $*${RC}"
    arch-chroot /mnt /bin/bash -c "$*" | sed 's/^/    /'
}

RCH sed '/^#\[multilib\]/s/^#//n;/^#Include/s/^#//' /etc/pacman.conf

#[multilib]
#Include ...

Here is what I need:

  • Search for a line starting with #[multilib]. If found, uncomment it.
  • Move to the next line and search for a line starting with #Include. If found, uncomment it. Then stop, no further searching or modifications.

Update: I thank you all very much for guiding me in the right direction. I modified the script like this, and so far, everything works except space key to continue.

WAIT() {
    echo -e "Press ${GC}SPACE${RC} to continue or ${GC}ESC${RC} to exit .."
    while true; do        
        read -n 1 -s key
        if [[ $key == " " ]]; then
            break
        elif [[ $key == $'\e' ]]; then
            exit 0
        fi
    done
}
RUN() {
    echo -e "${YC}    $*${RC}"
    WAIT
    /bin/bash -c "$@" | sed 's/^/      /'
}
RUN "sed -i '/^#\[multilib\]/{s/^#//;n;/^#Include/s/^#//}' /etc/pacman.conf"
RUN "echo LANG=${LOCALE} > /etc/locale.conf"
RUN "cat <<EOL > /etc/hosts
127.0.0.1   localhost
::1         localhost
EOL"
Improve this question
6
  • What is the generic idea/target? For me this is like XY problem. Commented Dec 17, 2024 at 10:37
  • 5
    set -x sounds like what you want. It prints all commands the shell executes, with the variables etc. expanded. Put the set -x at the top of the script (or set -o xtrace if you like the more verbose variant) Commented Dec 17, 2024 at 10:46
  • 5
    You say it isn't working, can you explain how it isn't working? What were you expecting to happen and what actually happens? Commented Dec 17, 2024 at 10:58
  • @RomeoNinov Generally, I want every command to be displayed before its execution. Later, I would add options to proceed or skip the command, but I'm not sure if my function is written correctly or if it just creates additional problems. Commented Dec 17, 2024 at 22:01
  • 1
    @Suggorath That is an important aspect of the problem; please edit the question to include it. Commented Dec 18, 2024 at 14:31

2 Answers 2

Reset to default
2

Not a complete answer, but note that this...

/bin/bash -c "$*"

...will not do what you want. Let's simplify your RCH function to:

RCH() {
  /bin/bash -c "$*"
}

Consider the behavior if we do something like this:

RCH sed 's/hello world/goodnight moon' somefile.txt

You get:

sed: -e expression #1, char 7: unterminated `s' command

And that's because you're discarding the tokenization of the original command. Instead of passing two arguments to sed (s/hello world/goodnight moon/ and somefile.txt), you're effectively running the command without quotes:

sed s/hello world/goodnight moon/ somefile.txt

That's four arguments (s/hello, world/goodnight, moon/, somefile.txt), and that's an invalid command. This is a contrived example, of course, but it's very easy to run into situations where this is a real problem.

You can get the appropriate behavior if you instead write:

RCH() {
  bash -c '"$@"' -- "$@"
}

(The -- is just a placeholder for $0 so that the first argument to RCH becomes $1 in the subshell.)

This will preserve the original tokenization of the command line:

$ echo hello world > somefile.txt
$ RCH sed 's/hello world/goodnight moon/' somefile.txt
goodnight moon
Improve this answer
2
  • 1
    -s conflicts with -c. -s is to take the code from stdin while allowing extra arguments, while -c is to take the code as the next argument instead (and in any case accepting extra arguments). I won't used -- for $0. The value of $0 is also used in error messages for instance, so having -- there would be confusing. I'd do /bin/sh -c 'exec "$@"' sh "$@" or just "$@", (or /usr/bin/env "$@" if the reason for using sh/bash is that arch-chroot can't do $PATH lookup of commands). Commented Dec 18, 2024 at 6:21
  • Yeah, not sure what I was thinking there. Good catch! Commented Dec 18, 2024 at 19:36
0

My suggestion is to print/echo all your command to the screen. Read them and check that they are correct, then: re-run the command but pipe it to a shell. (./cmds.sh | /bin/sh)

Better yet, redirect to a file and then execute the file; that way, if everything goes kablooie, at least the cause will be in the file.

...Because, running commands like that from the innards of a shell-program is disaster.

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.