Hello,
Recently I've tried to use BASH to do some binary operations, that task turned
out to be far more difficult, that I could ever imagined.
First of all, I've found out that 2 shifted to the left edge of boundary
(2**63) produces as a result a negative number "-9223372036854775808" ("funny"
On Sun, Mar 12, 2017 at 4:15 AM, wrote:
> Hello,
>
> Recently I've tried to use BASH to do some binary operations, that task
> turned out to be far more difficult, that I could ever imagined.
Bash has limited support for arithmetic operations on fixed width
signed integer numbers. Furthermore, i
For example:
$ PS1='\w $(echo \w) $ '
~ /home/levit $
Obviously, this is easy enough to work around in most cases by
replacing \w with ${PWD/#$HOME/~}. I had a silly application for
calculating prompt length and this was throwing it off, but this
behavior has been there since at least 2.05b so n
These expansions both seem to get values that are inconsistent when
expanded in the various prompt strings.
For example, starting with the following:
PS0='PS0 \! \# _ \n'
PS1='PS1 \! \# $ '
PS2='PS2 \! \# > '
PS4='PS4 \! \# + '
PSV='PSV \! \# V '
set -x
The prompts evaluate like so:
PS1 529 45
The manual says [1]:
In addition, the following table describes the special characters which can
appear in the prompt variables PS1 to PS4:
..which misses PS0 (and seems to imply that PS3 gets expanded in this
fashion as well).
[1] https://www.gnu.org/software/bash/manual/bash.html#Con
On Sun, 12 Mar 2017, Grisha Levit wrote:
For example:
$ PS1='\w $(echo \w) $ '
~ /home/levit $
This seems to work as documented, for the same reason this happens:
╶➤ echo ~
/home/rob
The expansion order is perhaps non-obvious: the prompt string backslash
escapes are replaced before the str
As a minimal example:
LC_CTYPE=en_US.UTF-8
PS1='\n\[\e[0m\]'
# put something into history:
echo foo
# ^R search for something that should put point in the middle of the string
(reverse-i-search)`fo': echo foo
# attempt to exit with end-of-line (^E)
echo foo
^<---point is here
Trying
