Greg Wooledge wrote:
> On Sun, Apr 21, 2013 at 12:25:20AM -0700, Linda Walsh wrote:
>> If I 'reedit my last "statement", it indents 8 spaces/tab.
>
> What does this sentence mean? I am completely stumped. What is
> the sequence of steps you are actually performing?
---
Type in this:
echo 'while read fn;do
<tab>d=${fn%.zip}
<tab>(
<tab><tab>cd "$d" && {
<tab><tab><tab>base=${d%-*}
<tab><tab><tab>if [[ -e $base.exe ]] ;then
<tab><tab><tab><tab>mv "$base.exe" "$d.exe" && ln -s "$d.exe"
"$base.exe"
<tab><tab><tab>fi
<tab><tab><tab>cp * ../bin
<tab><tab>}
<tab>)
done'
-----
Note, hit the tab key for <tab>, don't type in 5-char-string meaning tab!.
Now, for me, the above looks like:
while read fn;do
d=${fn%.zip}
(
cd "$d" && {
base=${d%-*}
if [[ -e $base.exe ]] ;then
mv "$base.exe" "$d.exe" && ln -s "$d.exe"
"$base.exe"
fi
cp * ../bin
}
)
done
when I have my terminal's HW tabstop set to every 2 columns.
But when I ***re-edit** the line... (I'm in vi-mode, so it's "<ESC>k">)
Bash will redisplay the echo line -- But instead of the displayed line
being displayed as output from echo (or cat), BASH when it redisplays the line,
doesn't use the actual TAB character when displaying the line. Instead
it expands the TAB chars to spaces, and as a result, gets it wrong.
By not using the actual tab character when it echo's out the re-edit line, it
has
2 effects -- 1: it doesn't display properly if someone has their tab stop set
to other than 8-spaces/tab, and 2) if you cut/paste the text -- the text no
longer contains embedded tabs but contains spaces.
I.e. when I cut/copy text from my terminal screen that was written with tabs,
the tabs are in the buffer -- not spaces. so when I paste it, the text is
the same as the source. Applications that convert it to text disable a clean
roundtrip copy/paste ability.
