Re: readline 'unix-filename-rubout' whitespace bug

2021-08-31 Thread Dabrien 'Dabe' Murphy

On 8/27/21, 5:22 PM, Dabrien 'Dabe' Murphy wrote:

On 8/27/21, 4:09 PM, Chet Ramey wrote:
That circumstance is a pathname consisting solely of  one or more 
slashes,

separated from the previous word by whitespace. I'll fix it.

The code has been like this since January, 2004. That's pretty dated.


I guess I was just hoping somebody smarter than me [that's not hard] would
bust out some super fu and say something like, "Have you tried adding
'set word-break-chars [blah]' to your .inputrc ?"  «grin»


[FWIW, I'm sure the "bug-bash" list isn't actually the right venue for 
this, and I
apologize, but I figured I'd send this along as a reply, just for 
posterity...]


Although the following doesn't — slash *CAN'T* ? — save to the kill ring 
(it doesn't

even attempt to keep track of $READLINE_MARK), I came up with the following
"clever workaround" [read: "gross hack"] to wrangle even bash 3.2 into 
submission:


prompt% less ~/.bash_readline
...
### Set up macro (shell function) to eval
unix_filename_rubout() {
local removed_space=0 removed_slash=0

while [[ ${READLINE_POINT:-0} -gt 0 ]] &&
  [[ ${READLINE_LINE: $((READLINE_POINT - 1)): 1} =~ ^\ ?$ ]]; do
READLINE_LINE="${READLINE_LINE: 0: $((READLINE_POINT - 
1))}${READLINE_LINE: $((READLINE_POINT--))}"

removed_space=1
done

while [[ ${READLINE_POINT:-0} -gt 0 ]] &&
  [[ ${READLINE_LINE: $((READLINE_POINT - 1)): 1} =~ ^/?$ ]]; do
READLINE_LINE="${READLINE_LINE: 0: $((READLINE_POINT - 
1))}${READLINE_LINE: $((READLINE_POINT--))}"

removed_slash=1
done

if ! { [[ ${removed_slash:-0} -ge 1 ]] && [[ ${removed_space:-0} 
-ge 1 ]]; }; then

removed_space=0
while [[ ${READLINE_POINT:-0} -gt 0 ]] &&
  [[ ${READLINE_LINE: $((READLINE_POINT - 1)): 1} =~ ^\ ?$ 
]]; do
READLINE_LINE="${READLINE_LINE: 0: $((READLINE_POINT - 
1))}${READLINE_LINE: $((READLINE_POINT--))}"

removed_space=1
done
else
removed_space=0
fi

if ! { [[ ${removed_slash:-0} -ge 1 ]] && [[ ${removed_space:-0} 
-ge 1 ]]; }; then

while [[ ${READLINE_POINT:-0} -gt 0 ]] &&
! [[ ${READLINE_LINE: $((READLINE_POINT - 1)): 1} =~ ^[\ 
/]?$ ]]; do
READLINE_LINE="${READLINE_LINE: 0: $((READLINE_POINT - 
1))}${READLINE_LINE: $((READLINE_POINT--))}"

done
fi
}

stty werase undef
bind -x '"\C-w": unix_filename_rubout'


You know what they say...  "If it's stupid but it works, it isn't 
stupid."  «grin»


Thanks!  :-D

--
:- Dabe


help adding some features to 5.1

2021-08-31 Thread Ananth Chellappa
Hi Team,
   Could I get some help locating portions of the code that would need
to be tweaked to add these features?

If I had the time, I would love to get to know the code, but I have too
much going on in my real job.

1. Intelligent support for !$ (and related - like !2$, !-N, etc) : This
means - ignore the & at the end of the previous command.
2. Autocomplete for !$ (and related tokens) : This means - if I have typed
!$ and now press TAB, I want the last word from the previous command
substituted on the command-line immediately.

Thanks sincerely,
Ananth


Re: Squiggly heredoc - new feature request

2021-08-31 Thread Lawrence Velázquez
On Tue, Aug 31, 2021, at 4:02 AM, Lawrence Velázquez wrote:
> ksh does not blindly remove all leading whitespace

For the curious, this is how ksh(1) describes it:

If '#' is appended to '<<', then leading spaces and tabs
will be stripped off the first line of the document and up
to an equivalent indentation will be stripped from the
remaining lines and from 'word'.  A tab stop is assumed to
occur at every 8 columns for the purposes of determining
the indentation.

-- 
vq



Re: Squiggly heredoc - new feature request

2021-08-31 Thread Oğuz
31 Ağustos 2021 Salı tarihinde Jesse Hathaway  yazdı:

> On Tue, Aug 31, 2021 at 2:24 AM Přemysl Šťastný  wrote:
> >
> > Thanks for advice. How do you use it in more detail please?
>
> You can feed shfmt an individual file to format, it defaults to
> using tabs for indentation:
>
>   $ shfmt ~/test.sh
>   #!/bin/bash
>
>   cat <<-EOF
>   hello!
>   EOF
>
> Or you can instruct your editor to run shfmt everytime you save. For
> example I
> use Vim with the github.com/dense-analysis/ale plugin configured to run
> shfmt
> every time I save.
>
>
Sounds more laborious than formatting by hand.


-- 
Oğuz


Re: Squiggly heredoc - new feature request

2021-08-31 Thread Jesse Hathaway
On Tue, Aug 31, 2021 at 2:24 AM Přemysl Šťastný  wrote:
>
> Thanks for advice. How do you use it in more detail please?

You can feed shfmt an individual file to format, it defaults to
using tabs for indentation:

  $ shfmt ~/test.sh
  #!/bin/bash

  cat <<-EOF
  hello!
  EOF

Or you can instruct your editor to run shfmt everytime you save. For example I
use Vim with the github.com/dense-analysis/ale plugin configured to run shfmt
every time I save.



Re: bash command alias has a problem in using brace.

2021-08-31 Thread Chet Ramey

On 8/27/21 9:47 PM, Dale R. Worley wrote:

Hyunho Cho  writes:



but if i use alias then '>' prompt does not appear and default bash
prompt appears

bash$ alias myalias='{ cat <<\@ > foo ;} 2> /dev/null'
bash$ myalias
bash$ 111
bash$ 222  # bash$ prompt
bash$ @





I don't know the details, but it must have something to do with what
event triggers the reading of the here-document.  That event isn't the
execution of the command containing it, I don't think, but more like
when the here-document-redirection is parsed. 


This is substantially correct. When the parser goes and collects the body
of the here-document, it's still parsing the contents of the alias.

--
``The lyf so short, the craft so long to lerne.'' - Chaucer
 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/



Re: Squiggly heredoc - new feature request

2021-08-31 Thread felix
Hi,

> ... ignoring both leading spaces and leading tabs. eg.

Something like (there must be nothing but tabulation before closing ``EOF'')?

  func(){
    sed 's/^ \{2\}//' <<- EOF
      blabla
      EOF
  }

Depending on how and why, there is a lot of *variants*:
 - leading spaces and/or/not leading tabs
 - trailing spaces and/or/not trailing tabs
 - keeping rest of line structure as is or replacing every number of
 spaces/tabs by one space
 - ...

Even merging lines like `xargs` does, there is a way I've used in some scripts,
  ( like https://f-hauri.ch/vrac/live-install.sh.txt ):

   myXargs() { sed -ne '/#/d;s/ \t//g;H;${x;s/\n/ /g;s/^ //;p}'; }

   This drop lines containing `#`, every spaces and merge all line as space
   separated words. I use this as:

   ExtraBootParams=$(myXargs <<-eobp
   boot=live
   config
   #   locales=de_CH
   locales=fr_CH
   keyboard-layouts=ch
   keyboard-variant=fr
   persistent=cryptsetup
   persistence-encryption=luks
   persistence
   eobp
   )
   PackageList=$(myXargs <<-eopl
   gnome
   gnome-core
   # gnome-full
   # debian-forensics
   debian-installer-launcher
   eopl
   )

On Mon, Aug 30, 2021 at 10:06:37PM +0200, Přemysl Šťastný wrote:
> 
> I think, it would be nice, if you implemented Squiggly heredoc, which solves
> this problem by ignoring both leading spaces and leading tabs. eg.
> 
> func()(
>   cat <<~ EOF
>     blabla
>   EOF
> )
> 


-- 
 Félix Hauri  --  http://www.f-hauri.ch



Re: Squiggly heredoc - new feature request

2021-08-31 Thread Lawrence Velázquez
> On Aug 31, 2021, at 3:16 AM, Přemysl Šťastný  wrote:
> 
> I didn't realize yesterday, that ksh93 is not a nick name, but ksh version 
> 93. :D

Sort of.

> So it would be okey with you, if I try to implement it using <<#?

The bash maintainer (who is not me) hasn’t yet indicated whether this is 
something he’d be interested in pursuing. The behavior is underspecified (ksh 
does not blindly remove all leading whitespace), and there are still 
compatibility concerns (as I mentioned earlier, there is currently at least one 
circumstance in which ‘<<#’ is valid syntax).

> Is there any git repo of bash?

Yes.

https://savannah.gnu.org/git/?group=bash

-- 
vq
Sent from my iPhone

Re: Squiggly heredoc - new feature request

2021-08-31 Thread Přemysl Šťastný

Thanks for advice. How do you use it in more detail please?

On 8/30/21 11:48 PM, Jesse Hathaway wrote:

Will ksh93 version ever get to upstream? This ugly 'bug' is here for
decades and really irritates me and many people, who ever used shell for
larger scripting and don't like to use tabs.

I used to always prefer spaces, until I switched to auto formatting all my Bash
scripts with shfmt[1]. It allows me to have indented heredocs and not worry
about manual formatting.

[1]: https://github.com/mvdan/sh




OpenPGP_0x2FD4F23C65C1A5F0_and_old_rev.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature


Re: Squiggly heredoc - new feature request

2021-08-31 Thread Přemysl Šťastný
I didn't realize yesterday, that ksh93 is not a nick name, but ksh 
version 93. :D


So it would be okey with you, if I try to implement it using <<#?

Is there any git repo of bash?

Thanks.
P.

On 8/30/21 11:43 PM, Lawrence Velázquez wrote:

On Mon, Aug 30, 2021, at 5:22 PM, Přemysl Šťastný wrote:

Will ksh93 version ever get to upstream?

I don't know what you mean by that.  ksh is not "downstream" of
bash; it is a separate project.  Whether bash incorporates this
feature or one like it is up to Chet, who hasn't yet chimed in.


This ugly 'bug' is here for decades and really irritates me
and many people, who ever used shell for larger scripting and
don't like to use tabs.

I don't really have an opinion.  To me it's just another shell
scripting wart to get used to, and not even the ugliest one.
I would just prefer that a potential implementation not diverge
from prior art needlessly.





OpenPGP_0x2FD4F23C65C1A5F0_and_old_rev.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature