Re: Shell-script[bash] indention broken (or fixed?)

[Steven T. Hatton]

On Sunday 12 June 2005 07:19, Glenn Morris wrote:
> Richard Stallman wrote:
> >     Until recently the behavior of Shell-script[bash] mode was to
> >     not indent the second of the following two lines when tab was hit:
> >
> >     export VARIABLE=/path/to/here\
> >
> >     :/path/to/there
> >
> >     Now it indents it like this:
> >
> >     export VARIABLE=/path/to/here\
> >
> >     :/path/to/there
> >
> > I loaded a version of sh-script.el from September and it gave the
> > latter result.  So this is not, I believe, the result of a recent
> > change.
>
> For the record, the behaviour is the same in Emacs-21.3 as well. I
> don't recall ever seeing the former result. It seems to have worked
> the way it does now for >~ 5 years.
I have no idea why things recently changed on my box, but I am certain beyond 
doubt that the behavior did, in fact, change.  Had this not happened, I would 
not have even suspected the existence of the option specifying the 
non-indenting behavior.  The previous behavior may have been due to something 
I recently took out of my .emacs.
 

> Sometimes (as in this case) yes, but most of the time (for the shell
> scripts I write) no. My continuation lines tend to look like:
>
> command_with_a_lot_of_arguments arg1 arg2 arg3 arg4 \
>      arg5 arg6...
>
> or:
>
> command1 && \
>      command2
>
>
> Personally, I like and find useful the indentation of the continued
> lines. It's almost never inappropriate (for me); though one could even
> write weird things like:
>
> this_is_a_single_\
> command_name
>
>
> which should not be indented. There's no way to tell whether
> indentation of a continued line is wrong, so it's a question of what
> the default should be. I vote for the current arrangement.

To my way of thinking, the '\' says I'm breaking the line for the sake of the 
human reader, but the computer should not see the linebreak. The places I use 
the '\' continuation are with long path definitions, and with continued 
commands as you have shown above.  Mine typically look like this:

#!/bin/bash
pushd /download/org/gnu/emacs/emacs &&\
 cvs update -dPAC &&\
 pushd /download/org/gnu/emacs/emacs-build &&\
 make clean &&\
 ../emacs/configure --prefix=$GNU_EMACS &&\
 make -j8 &&\
 pushd lisp &&\
 make recompile EMACS=../src/emacs &&\
 popd &&\
 make install &&\
 popd

I am less confident of this, but I seem to recall that hitting tab on one of 
the above continued lines would not left justify it if the space was already 
there.  I'll have to try and reproduce the previous behavior before I comment 
on it further.

As for whether the default should be to indent, or not to indent, I have to 
say the line should be treated as if it were a single line of text, and 
should preserve whatever is already present.  This may, in fact, be the 
behavior I was previously observing.  I may never have written

export PATH=$HOME/bin\
:$KDEDIR/bin\
:$QTDIR/bin\
:$PATH\
:$NSS/bin\
:$NSPR/bin\
:$MONO_HOME/bin\
:$BOOST_HOME/bin\
:$XINE_HOME/bin

in a way that would have changed when I hit tab.  The surprise was when I hit 
tab and it did change.  I will investigate further.

My reasoning for preserving the original text as if it were all one line is 
that the other options (left justifying, or indenting) can change the 
semantic meaning of the statement being continued.  C-x C-h C-M-\ should not 
change the semantics of the content.  With a large buffer, that may go 
unnoticed, and introduce a bug in the script.

BTW, Richard, I know I'm still on the hook for the debug output for the crash 
while visiting a file bug.  I'm trying to read the GDB manual, but, alas, the 
EDE bug is not the only bug I've hit in the past two weeks.
-- 
Regards,
Steven