Re: documentation bug re character range expressions
On 2011-06-09 12:40 -0700, Marcel (Felix) Giannelia wrote: > Guess it's time I really learned how to navigate texinfo... You can spare yourself the pain with something along the lines of #!/bin/sh info --subnodes -o- "$1" | less (Which won't help you in this particular case as neither bash nor bash-doc contain any .info files, at least not on Debian.) -- André Majorel http://www.teaser.fr/~amajorel/
Re: Built-in printf Sits Awkwardly with UDP.
On 2011-07-20 14:34 +0100, Ralph Corderoy wrote: > No. Here's my understanding of how it currently works. The built-in > printf works out a character to print at a time; no foresight needed or > used. It asks the C library to print it with putchar(3). The C library > can implement buffering to avoid too many expensive write(2) system > calls. bash has the C library buffer stdout by lines. Each time > putchar(3) is called the character is appended to the buffer. If the > character was '\n' or the buffer is now full then write(2) is called to > pass the buffer to the kernel and the buffer then treated as empty. > > When printf is finished the buffer is flushed, e.g. if there's anything > in it then write(2) is called. > > The C library provides two other modes of buffering, see setvbuf(3). > bash could easily detect that stdout is a regular file, have a new > stream be duplicated from file descriptor 1, and set it to > block-buffered. If standard output is a log file, log entries could remain latent for a very long time. The buffering mode we really want is buffered with a forced flush at reasonable intervals, E.G. one second after the last write. Unfortunately, there's no such thing in stdio. -- André Majorel http://www.teaser.fr/~amajorel/
Readline : move to previous/next path component
One frequently needed function that readline does not seem to have is a way to move to the beginning of the next or previous path component. This is what I've come up with : \C-t: "\C-b\C-b\e\C-]/\C-f" \C-y: "\C-]/\C-f" Three problems with this kludge : 1. The definition uses keys, not functions. Is there a way to mix functions and string literals in a readline binding ? 2. If you press ^Y while past the last slash in a word, the cursor moves to the first slash in the next word if there is one, or the next character otherwise. It would be more useful to move immediately past the end of the current word. 3. If you press ^T while you're already on the first slash in a word, the cursor moves to the last slash in the previous word if there is one, or the previous character otherwise. It would be more useful to move to the beginning of the current word. Is there a better way ? Thanks in advance. -- André Majorel http://www.teaser.fr/~amajorel/> You measure democracy by the freedom it gives its dissidents, not the freedom it gives its assimilated conformists -- Abbie Hoffman.
Re: Readline : move to previous/next path component
On 2008-10-15, Chet Ramey <[EMAIL PROTECTED]> wrote: > Andre Majorel wrote: >> One frequently needed function that readline does not seem to >> have is a way to move to the beginning of the next or previous >> path component. > > Readline doesn't have any built-in knowledge of Unix pathnames. For my edification, is the relative lack of Unix/shell support due to 1. "can of worms", 2. "readline is supposed to be general", 3. "there is no need for it" ? > You might want to take a look at emacs-mode M-b, which moves backward > by strings of alphabetic characters, and M-f, which moves forward. > You might have to play around with a macro that moves forward additional > characters past the `/', but that should get you further. Thanks, but that would be even worse. Instead of just breaking down at the ends of pathnames, it will break every time a path component contains a non-letter, which is often for me. -- André Majorel http://www.teaser.fr/~amajorel/> You measure democracy by the freedom it gives its dissidents, not the freedom it gives its assimilated conformists -- Abbie Hoffman.
Re: Readline : move to previous/next path component
On 2008-10-15, Chet Ramey <[EMAIL PROTECTED]> wrote: >> On 2008-10-15, Chet Ramey <[EMAIL PROTECTED]> wrote: >> > Andre Majorel wrote: >> >> One frequently needed function that readline does not seem to >> >> have is a way to move to the beginning of the next or previous >> >> path component. >> > >> > Readline doesn't have any built-in knowledge of Unix pathnames. >> >> For my edification, is the relative lack of Unix/shell support >> due to >> 1. "can of worms", >> 2. "readline is supposed to be general", >> 3. "there is no need for it" ? > > Mostly the second one, mixed with the fact that nobody's requested > this particular feature before. Readline is very extensible; bash > adds quite a lot to the basic framework -- look at all the code in > bashline.c. OK. Unfortunately, the hackability appears to be at the source level, not at the .inputrc level. For most Bash users, maintaining your own binaries is inconvenient. > If you'd like to take a crack at writing a bindable readline > command to do what you want, I'd certainly look at it for a > future version. (You'll probably get to it before I would.) I think the thing I've missed the most in readline, besides an understanding of Unix pathnames, is an understanding of shell quoting. Sometimes I'd like to be able to delete or move over A\ Very\ Long\ Directory\ Name/A\ Very\ Long \ File\ Name or 'Another file name that'\''s got inverted commas in it' in one operation. character-search and character-search-backward sometimes help but they're bound to ^] which cannot be entered at the Linux console on an AZERTY keyboard. Vi mode would help, but in Bash, there's no way to switch between it and Emacs mode on the fly. No time to look into it at the moment, but sooner or later, frustration will win... -- André Majorel http://www.teaser.fr/~amajorel/> You measure democracy by the freedom it gives its dissidents, not the freedom it gives its assimilated conformists -- Abbie Hoffman.
Re: Readline : move to previous/next path component
On 2008-10-16, Aharon Robbins <[EMAIL PROTECTED]> wrote: > In article <[EMAIL PROTECTED]>, > Andre Majorel <[EMAIL PROTECTED]> wrote: >>Vi mode would help, but in Bash, there's no way to switch >>between it and Emacs mode on the fly. > > Au contraire: > > set -o vi > set -o emacs By "on the fly", I didn't mean in the middle of a Bash session but in the middle of editing a command line. For some reason, Esc ^J is a no-op in Bash. -- André Majorel http://www.teaser.fr/~amajorel/> You measure democracy by the freedom it gives its dissidents, not the freedom it gives its assimilated conformists -- Abbie Hoffman.
Re: Readline : move to previous/next path component
On 2008-10-16, Larry Clapp <[EMAIL PROTECTED]> wrote:
> On Thu, Oct 16, 2008 at 09:12:23AM +0000, Andre Majorel wrote:
>> On 2008-10-16, Aharon Robbins <[EMAIL PROTECTED]> wrote:
>> > In article <[EMAIL PROTECTED]>,
>> > Andre Majorel <[EMAIL PROTECTED]> wrote:
>> >>Vi mode would help, but in Bash, there's no way to switch between
>> >>it and Emacs mode on the fly.
>> >
>> > Au contraire:
>> >
>> >set -o vi
>> >set -o emacs
>>
>> By "on the fly", I didn't mean in the middle of a Bash session but
>> in the middle of editing a command line. For some reason, Esc ^J is
>> a no-op in Bash.
>
> That's because it's not bound:
>
> zsh> bash
> [EMAIL PROTECTED]:~$ bind -m emacs -p | grep -i m-.c-j
> [ no output ]
> [EMAIL PROTECTED]:~$ bind -m vi -p | grep -i c-e
> [ no output ]
More precisely, because it's been explicitly unbound :
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=198634
| "Marcelo E. Magallon" :
| Oh, btw, I can't get C-M-j to work. Perhaps I need to
| figure out which key is Meta. I thought it was "Alt" (which
| xkeycaps confirms), but no cigar...
|
| Chet Ramey :
| It doesn't work in bash. Bash disables it because `set -o
| emacs' and `set -o vi' exist. There is text in the readline
| manual that is conditionally included depending on whether or
| not the text is part of the bash manual or standalone. The
| standalone version includes the M-C-j stuff; the bash version
| includes `set -o {emacs,vi}'
If you don't quite see the relationship of cause and effect
implied by the word "because" between "set -o {vi,emacs} exist"
and "Bash disables [M-C-j]", me neither, but there you have it.
> But you can bind the standard Readline keys for those commands:
>
> [EMAIL PROTECTED]:~$ bind -m emacs '"\e\C-J": vi-editing-mode'
> [EMAIL PROTECTED]:~$ bind -m vi '"\C-E": emacs-editing-mode'
Thanks, that worked. Put this in my .inputrc (not tested in vi
mode) :
# [ù] to switch between vi and Emacs mode
set keymap emacs
ù: vi-editing-mode
set keymap vi-command
ù: emacs-editing-mode
set keymap vi-insert
ù: emacs-editing-mode
set keymap vi-move
ù: emacs-editing-mode
With this, you can move to the next-to-last path component with
[ù] [Esc] [2] [T] [/] [ù]
(7 key presses) instead of the wrist-twisting, console-verboten
[Esc] [Ctrl]-[]] [/] [Esc] [Ctrl]-[]] [/] [Right]
(13 key presses). Still, not nearly as good as
[Ctrl]-[T] [Ctrl]-[T]
(3 key presses).
One problem solved, four to go.
--
André Majorel http://www.teaser.fr/~amajorel/>
You measure democracy by the freedom it gives its dissidents, not
the freedom it gives its assimilated conformists -- Abbie Hoffman.
Issuing re-read-init-file from a Bash function
How do you force a reload of ~/.inputrc from a Bash function ? All "bind re-read-init-file" seems to do is make the [f] key go away. Thanks in advance. -- André Majorel http://www.teaser.fr/~amajorel/
Verbatim pasting
Binding printable ASCII characters to readline functions is convenient but it can bite you when you paste text into a shell. Is there a way to bypass readline while pasting ? Something like a ^V toggle or a ^V that lasts until the next newline or next pause between two characters longer than 250 ms or... -- André Majorel http://www.teaser.fr/~amajorel/
Re: Verbatim pasting
On 2010-08-10 16:05 -0400, Mike Frysinger wrote: > On Tue, Aug 10, 2010 at 2:08 PM, Andre Majorel wrote: > > Binding printable ASCII characters to readline functions is > > convenient but it can bite you when you paste text into a shell. > > > > Is there a way to bypass readline while pasting ? Something like > > a ^V toggle or a ^V that lasts until the next newline or next > > pause between two characters longer than 250 ms or... > > are you trying to write that text to a file or something ? I wish I were, I could just type "cat >file" before pasting and ^D after. No, it's just strings, file names, whole command lines, that sort of stuff. -- André Majorel http://www.teaser.fr/~amajorel/
Re: \c escape within $'...' can produce mangled UTF-8
On 2010-08-15 01:08 +0400, Dmitry Groshev wrote: > If an escape's parameter makes no sense, escape sequence should be > left untranslated - just the way "\x" handles things like "\xZZ". Make > "\c" check that its parameter is an ASCII char, and the problem will > be fixed. > Unless for some reason you consider this bug worth preserving. :-) Guess the code blindly outputs the next char & 0x1f. Which is a good thing in a way because if it did check that the next char is between 0x3f and 0x5e, there would be no way to produce "\x1c" through \c : $ sh <<\EOF printf '%s' $'\c\' | xxd EOF sh: line 1: unexpected EOF while looking for matching `'' sh: line 2: syntax error: unexpected end of file $ sh <<\EOF printf '%s' $'\c\\' | xxd EOF 000: 1c5c .\ Of course there's $'\x1c' and $'\034' so it's kind of moot. -- André Majorel http://www.teaser.fr/~amajorel/
Re: Encoding multiple filenames in a single variable
On 2010-08-29 17:12 +1000, Jon Seymour wrote: > This isn't strictly a bash question, and I'd prefer a POSIX-only > solution if possible [ suggestions as to a good question to ask > POSIX-only questions would be appreciated ]. comp.unix.shell > Suppose I need to encode a list of filenames in a variable and each > filename may contain spaces, what is good way to encode such a list so > that the resulting variable is readily compose-able and decodeable? In > particular, I'd like to avoid the use of (unescaped) separators which > might themselves be used in the filename. Depends. Where do those file names come from and how are they used ? Command line arguments ? File descriptor ? Separated by NULs or newlines ? One by one or all at once ? -- André Majorel http://www.teaser.fr/~amajorel/
Re: asking for a better way to implement this
On 2010-09-27 18:39 +0200, Christopher Roy Bratusek wrote:
> I'm using GNU/Linux for seven years now, it's now almost
> impossible to learn to use `xrm' instead of `rm'.
Put rm(){su} in your .bashrc. You'll be surprised. :->
--
André Majorel http://www.teaser.fr/~amajorel/
syntax error near unexpected token `time'
Funny one : $ bash -c 'echo a | time cat' a [/usr/bin/time output deleted] On the other hand : $ bash -c 'echo a | time cat' bash: -c: line 1: syntax error near unexpected token `time' bash: -c: line 1: `time cat' [$PS2 deleted] Dash, ksh and zsh accept either form. That was with Bash 4.2.37. If it's been fixed in a later version, sorry for the noise. -- André Majorel http://www.teaser.fr/~amajorel/
Re: syntax error near unexpected token `time'
On 2014-12-14 21:12 -0500, Chet Ramey wrote: > Yes, `time' should not be recognized as a reserved word in this case, even > though the previous token is a newline. I'll take a look at it. Thanks > for the report. Note that the error occurs even if there is white space between the newline and "time". Thank you Chet, Eduardo and Piotr. -- André Majorel http://www.teaser.fr/~amajorel/
