Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

I’d like to implement a function in Bash which increases (and returns) a count with every call. Unfortunately this seems non-trivial since I’m invoking the function inside a subshell and it consequently cannot modify its parent shell’s variables.

Here’s my attempt:

PS_COUNT=0

ps_count_inc() {
    let PS_COUNT=PS_COUNT+1
    echo $PS_COUNT
}

ps_count_reset() {
    let PS_COUNT=0
}

This would be used as follows (and hence my need to invoke the functions from a subshell):

PS1='$(ps_count_reset)> '
PS2='$(ps_count_inc)   '

That way, I’d have a numbered multi-line prompt:

> echo 'this
1   is
2   a
3   test'

Cute. But due to the above mentioned limitation doesn’t work.

A non-working solution would be to write the count to a file instead of a variable. However, this would create a conflict between multiple, simultaneously running sessions. I could append the process ID of the shell to the file name, of course. But I’m hoping there’s a better solution which won’t clutter my system with lots of files.

share|improve this question
    
WRT collisions using a file stash see man 1 mktemp. –  goldilocks Apr 15 at 16:39
    
You should see my edit - I think you'll like it. –  mikeserv Apr 15 at 23:53

5 Answers 5

up vote 12 down vote accepted

enter image description here

To get the same output you note in your question, all that is needed is this:

PS1='${PS2c##*[$((PS2c=0))-9]}- > '
PS2='$((PS2c=PS2c+1)) > '

You need not contort. Those two lines will do it all in any shell that pretends to anything close to POSIX compatibility.

- > cat <<HD
1 >     line 1
2 >     line $((PS2c-1))
3 > HD
    line 1
    line 2
- > echo $PS2c
0

But I liked this. And I wanted to demonstrate the fundamentals of what makes this work a little better. So I edited this a little. I stuck it in /tmp for now but I think I'm going to keep it for myself, too. It's here:

cat /tmp/prompt

PROMPT SCRIPT:

ps1() { IFS=/
    set -- ${PWD%"${last=${PWD##/*/}}"}
    printf "${1+%c/}" "$@" 
    printf "$last > "
}

PS1='$(ps1)${PS2c##*[$((PS2c=0))-9]}'
PS2='$((PS2c=PS2c+1)) > '

Note: having recently learned of yash, I built it yesterday. For whatever reason it doesn't print the first byte of every argument with the %c string - though the docs were specific about wide-char extensions for that format and so it maybe related - but it does just fine with %.1s

That's the whole thing. There are two main things going on up there. And this is what it looks like:

/u/s/m/man3 > cat <<HERE
1 >     line 1
2 >     line 2
3 >     line $((PS2c-1))
4 > HERE
    line 1
    line 2
    line 3
/u/s/m/man3 >

PARSING $PWD

Every time $PS1 is evaluated it parses and prints $PWD to add to the prompt. But I don't like the whole $PWD crowding my screen, so I want just the first letter of every breadcrumb in the current path down to the current directory, which I'd like to see in full. Like this:

/h/mikeserv > cd /etc
/etc > cd /usr/share/man/man3
/u/s/m/man3 > cd /
/ > cd ~
/h/mikeserv > 

There are a few steps here:

IFS=/

we're going to have to split the current $PWD and the most reliable way to do that is with $IFS split on /. No need to bother with it at all afterward - all splitting from here on out will be defined by the shell's positional parameter $@ array in the next command like:

set -- ${PWD%"${last=${PWD##/*/}}"}

So this one's a little tricky, but the main thing is that we're splitting $PWD on / symbols. I also use parameter expansion to assign to $last everything after any value occurring between the left-most and right-most / slash. In this way I know that if I'm just at / and have only one / then $last will still equal the whole $PWD and $1 will be empty. This matters. I also strip $last from the tail end of $PWD before assigning it to $@.

printf "${1+%c/}" "$@"

So here - as long as ${1+is set} we printf the first %character of each our shell's arguments - which we've just set to each directory in our current $PWD - less the top directory - split on /. So we're essentially just printing the first character of every directory in $PWD but the top one. It's important though to realize this only happens if $1 gets set at all, which will not happen at root / or at one removed from / such as in /etc.

printf "$last > "

$last is the variable I just assigned to our top directory. So now this is our top directory. It prints whether or not the last statement did. And it takes a neat little > for good measure.

BUT WHAT ABOUT THE INCREMENT?

And then there's the matter of the $PS2 conditional. I showed earlier how this can be done which you can still find below - this is fundamentally an issue of scope. But there's a little more to it unless you want to start doing a bunch of printf \backspaces and then trying to balance out their character count... ugh. So I do this:

PS1='$(ps1)${PS2c##*[$((PS2c=0))-9]}'

Again, ${parameter##expansion} saves the day. It's a little strange here though - we actually set the variable while we strip it of itself. We use its new value - set mid-strip - as the glob from which we strip. You see? We ##*strip all from the head of our increment variable to the last character which can be anything from [$((PS2c=0))-9]. We're guaranteed in this way not to output the value, and yet we still assign it. It's pretty cool - I've never done that before. But POSIX also guarantees us that this is the most portable way this can be done.

And it's thanks to POSIX-specified ${parameter} $((expansion)) that keeps these definitions in the current shell without requiring that we set them in a separate subshell, regardless of where we evaluate them. And this is why it works in dash and sh just as well as it does in bash and zsh. We use no shell/terminal dependent escapes and we let the variables test themselves. That's what makes portable code quick.

The rest is fairly simple - just increment our counter for every time $PS2 is evaluated until $PS1 once again resets it. Like this:

PS2='$((PS2c=PS2c+1)) > '

So now I can:

DASH DEMO

ENV=/tmp/prompt dash -i

/h/mikeserv > cd /etc
/etc > cd /usr/share/man/man3
/u/s/m/man3 > cat <<HERE
1 >     line 1
2 >     line 2
3 >     line $((PS2c-1))
4 > HERE
    line 1
    line 2
    line 3
/u/s/m/man3 > printf '\t%s\n' "$PS1" "$PS2" "$PS2c"
    $(ps1)${PS2c##*[$((PS2c=0))-9]}
    $((PS2c=PS2c+1)) >
    0
/u/s/m/man3 > cd ~
/h/mikeserv >

SH DEMO

It works the same in bash or sh:

ENV=/tmp/prompt sh -i

/h/mikeserv > cat <<HEREDOC
1 >     $( echo $PS2c )
2 >     $( echo $PS1 )
3 >     $( echo $PS2 )
4 > HEREDOC
    4
    $(ps1)${PS2c##*[$((PS2c=0))-9]}
    $((PS2c=PS2c+1)) >
/h/mikeserv > echo $PS2c ; cd /
0
/ > cd /usr/share
/u/share > cd ~
/h/mikeserv > exit

As I said above, the primary problem is that you need to consider where you do your computation. You don't get the state in the parent shell - so you don't compute there. You get the state in the subshell - so that's where you compute. But you do the definition in the parent shell.

ENV=/dev/fd/3 sh -i  3<<\PROMPT
    ps1() { printf '$((PS2c=0)) > ' ; }
    ps2() { printf '$((PS2c=PS2c+1)) > ' ; }
    PS1=$(ps1)
    PS2=$(ps2)
PROMPT

0 > cat <<MULTI_LINE
1 > $(echo this will be line 1)
2 > $(echo and this line 2)
3 > $(echo here is line 3)
4 > MULTI_LINE
this will be line 1
and this line 2
here is line 3
0 >
share|improve this answer
1  
@mikeserv We’re turning in circles. I know all this. But how do I use this in my definition of PS2? This is the tricky part. I don’t think your solution can be applied here. If you think otherwise please show me how. –  Konrad Rudolph Apr 15 at 16:07
1  
@mikeserv No, that’s unrelated, sorry. See my question for details. PS1 and PS2 are special variables in the shell which are printed as the command prompt (try it by setting PS1 to a different value in a new shell window), they are thus used very differently from your code. Here’s some more info on their usage: linuxconfig.org/bash-prompt-basics –  Konrad Rudolph Apr 15 at 16:26
1  
@KonradRudolph what's to stop you from defining them twice? Which is what my original thing did... I have to look at your answer... This is done all of the time. –  mikeserv Apr 15 at 16:28
1  
@mikeserv Type echo 'this at a prompt, then explain how to update the value of PS2 before typing the closing single quote. –  chepner Apr 15 at 17:12
1  
Okay, this answer is now officially amazing. I also like the breadcrumbs, although I won’t adopt it since I print the full path in a separate line anyway: i.imgur.com/xmqrVxL.png –  Konrad Rudolph Apr 16 at 7:51

With this approach (function running in a subshell) you aren't going to be able to update the master shell process's state without going through contortions. Instead, arrange for the function to run in the master process.

The value of the PROMPT_COMMAND variable is interpereted as a command which is executed before printing the PS1 prompt.

For PS2, there's nothing comparable. But you can use a trick instead: since all you want to do is an arithmetic operation, you can use arithmetic expansion, which doesn't involve a subshell.

PROMPT_COMMAND='PS_COUNT=0'
PS2='$((++PS_COUNT))  '

The result of the arithmetic computation ends up in the prompt. If you want to hide it, you can pass it as an array subscript that doesn't exist.

PS1='${nonexistent_array[$((PS_COUNT=0))]}\$ '
share|improve this answer

It's a bit I/O-intensive, but you'll need to use a temporary file to hold the value of the count.

ps_count_inc () {
   read ps_count < ~/.prompt_num
   echo $((++ps_count)) | tee ~/.prompt_num
}

ps_count_reset () {
   echo 0 > ~/.prompt_num
}

If you are concerned about needing a separate file per shell session (which seems like a minor concern; will you really be typing multi-line commands in two different shells at the same time?), you should use mktemp to create a new file for each use.

ps_count_reset () {
    rm -f "$prompt_count"
    prompt_count=$(mktemp)
    echo 0 > "$prompt_count"
}

ps_count_inc () {
    read ps_count < "$prompt_count"
    echo $((++ps_count)) | tee "$prompt_count"
}
share|improve this answer
    
+1 The I/O is probably not very significant since if the file is small and being frequently accessed, it will be cached, i.e., it's essentially functioning as shared memory. –  goldilocks Apr 15 at 15:53

You can not use a shell variable this way and you already understand why. A subshell inherits variables exactly the same way a process inherits its environment: any changes made apply only to it and its children and not to any ancestor process.

As per other answers the easiest thing to do is stash that data in a file.

echo $count > file
count=$(<file)

Etc.

share|improve this answer
    
Of course you can set a variable in this way. You do not need a temp file. You set in the variable in the subshell and print its value to parent shell where you absorb that value. You get all of the state you need to compute its value in the subshell so that's where you do it. –  mikeserv Apr 15 at 16:07
1  
@mikeserv That's not the same thing, which is why the OP has said such a solution will not work (although this should have been made more clear in the question). What you are referring to is passing a value to another process via IPC so that it can assign that value to whatever. What the OP wanted/needed to do was affect the value of a global variable shared by a number of processes, and you cannot do that via the environment; it is not very useful for IPC. –  goldilocks Apr 15 at 16:17
    
Man, either I've completely misunderstood what is needed here, or everyone else has. It seems really simple to me. You see my edit? What's wrong with it? –  mikeserv Apr 15 at 16:27
    
@mikeserv I don't think you've misunderstood and to be fair, what you have is a form of IPC and could work. It's not clear to me why Konrad doesn't like it, but if it isn't flexible enough, then the file stash is pretty straightforward (and so are ways to avoid collisions, e.g. mktemp). –  goldilocks Apr 15 at 16:38
2  
@mikeserv The intended function is called when the value of PS2 is expanded by the shell. You don't have an opportunity to update the value of a variable in the parent shell at that time. –  chepner Apr 15 at 17:16

For reference, here’s my solution using temporary files, which are unique per shell process, and deleted as soon as possible (to avoid clutter, as alluded to in the question):

# Yes, I actually need this to work across my systems. :-/
_mktemp() {
    local tmpfile="${TMPDIR-/tmp}/psfile-$$.XXX"
    local bin="$(command -v mktemp || echo echo)"
    local file="$($bin "$tmpfile")"
    rm -f "$file"
    echo "$file"
}

PS_COUNT_FILE="$(_mktemp)"

ps_count_inc() {
    local PS_COUNT
    if [[ -f "$PS_COUNT_FILE" ]]; then
        let PS_COUNT=$(<"$PS_COUNT_FILE")+1
    else
        PS_COUNT=1
    fi

    echo $PS_COUNT | tee "$PS_COUNT_FILE"
}

ps_count_reset() {
    rm -f "$PS_COUNT_FILE"
}
share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.