Re: gcc fails to build w/bash-4.4_alpha
On 14 Jul 2015 09:17, Chet Ramey wrote: > The following patch removes the code that incorrectly optimizes the fork in > this case. There is a much more direct way to do what I want; that will be > in the next test release. thanks, patch works as advertised ;) -mike signature.asc Description: Digital signature
Re: auto-complete going on a diagonal -- "set print-completions-horizontally on => "equals diagonally"
Linda Walsh wrote:
Chet Ramey wrote:
Am still on 4.2, but in the bashdir, I get:
reset ... ^L
Erase is control-H (^H).
Kill is control-X (^X).
Ishtar:law> hhsfshsdfhl^C
Ishtar:law> bind
Ishtar:law> cd ../tools/bash/bash-4.3
Ishtar:tools/bash/bash-4.3> ls b
bash*bashintl.h bashversion* buildversion.o
bashansi.h bashjmp.hbracecomp.c builtins/
bashbug* bashline.c bracecomp.o builtins.h
bashhist.c bashline.h braces.c bashhist.h
bashline.o braces.o bashhist.o bashtypes.h
buildsignames.o
---
weird -- the last line above was extra long
In tbird they are lined up... 2 columns,,but the 3rd line from the top
is 96-97 chars wide -- i.e. on an 80-wide terminal, it would all be 1
column.
Before... when I turned it off, I had one screen where it printed in 1
column
for completion, so I don't know what causes it to switch into the mode where
it thinks my term is 90+ columns wide...
Ishtar:/suse132> ls e17
e17-0.17.6-2.1.10.x86_64.rpm
e17-branding-openSUSE-0.1-10.1.2.x86_64.rpm
e17-branding-upstream-0.17.6-2.1.10.x86_64.rpm
e17-devel-0.17.6-2.1.10.x86_64.rpm
e17-doc-html-0.17.6-2.1.10.x86_64.rpm
e17-profiles-openSUSE-20131019-2.1.4.noarch.rpm
e17-theme-a-os-agust-v3-1-2.1.9.noarch.rpm
e17-theme-a-os-detour-1-2.1.9.noarch.rpm
e17-theme-a-os-green-1-2.1.9.noarch.rpm
e17-theme-a-os-miguel-v3-1-2.1.9.noarch.rpm
e17-theme-a-os-vision-v3-1-2.1.9.noarch.rpm
e17-theme-darkness-81195-2.1.9.noarch.rpm
e17-theme-default-0.17.6-2.1.10.x86_64.rpm
e17-theme-edjy-1-2.1.9.noarch.rpm
e17-theme-openSUSE-20131101.1-2.1.9.noarch.rpm
Ishtar:/suse132> bind 'set print-completions-horizontally' off
Ishtar:/suse132> ls e17
e17-0.17.6-2.1.10.x86_64.rpm
e17-branding-openSUSE-0.1-10.1.2.x86_64.rpm
e17-branding-upstream-0.17.6-2.1.10.x86_64.rpm
e17-devel-0.17.6-2.1.10.x86_64.rpm
e17-doc-html-0.17.6-2.1.10.x86_64.rpm
e17-profiles-openSUSE-20131019-2.1.4.noarch.rpm
e17-theme-a-os-agust-v3-1-2.1.9.noarch.rpm
e17-theme-a-os-detour-1-2.1.9.noarch.rpm
e17-theme-a-os-green-1-2.1.9.noarch.rpm
e17-theme-a-os-miguel-v3-1-2.1.9.noarch.rpm
e17-theme-a-os-vision-v3-1-2.1.9.noarch.rpm
e17-theme-darkness-81195-2.1.9.noarch.rpm
e17-theme-default-0.17.6-2.1.10.x86_64.rpm
e17-theme-edjy-1-2.1.9.noarch.rpm
e17-theme-openSUSE-20131101.1-2.1.9.noarch.rpm
This is my home-dir ".inputrc", BTW,
grep -Pv "^#|^\s*$" ~/.inputrc
set history-size=-1
set completion-ignore-case on
set convert-meta off# don't strip high bit
set expand-tilde on
set input-meta on
set mark-directories on
set output-meta on
set menu-complete-display-prefix on
set print-completions-horizontally off
set show-all-if-unmodified on
set visible-stats on
"\C-p": paste-from-clipboard
$if mode=vi
set editing-mode vi
set keymap vi
$endif
$if pcalc
set editing-mode vi
set keymap vi
$endif
$if bash
set completion-map-case on
set completion-prefix-display-length=256
set keymap vi-insert
set expand-tilda on
set history-preserve-point on
set mark-symlinked-directories on
set page-completions on
set quoted-insert C-v
set show-all-if-ambiguous on
set tab-insert on
"\C-ep": "PATH=${PATH}\e\C-e\C-a\ef\C-f"
"\C-e\"": "\"\"\C-b"
"\C-e\\": "\\"
"\C-eq": "\eb\"\ef\""
"\C-er": redraw-current-line
"\M-\C-v": "\C-a\C-k$\C-y\M-\C-e\C-a\C-y="
$endif
"\M-t": transpose-chars
"\M-TAB": completion
"\M-u": upcse-word
"\M-l": downcase-word
"\M-c": capitalize-word
"\M-w": unix-filename-rubout
"\M-?": possible-completions
"\M-*": insert-completions
"\M-m": menu-complete
"\M-x(":start-kbd-macro
"\M-x)":end-kbd-macro
"\M-xe":call-last-kbd-macro
"\M-r":revert-line
"\M-&":tilde-expand
TAB:tab-insert
"\M-`":complete
"`":complete
"\C-a":dump-functions
"\C-b":dump-variables
"\C-t":dump-macros
Re: auto-complete going on a diagonal -- "set print-completions-horizontally on => "equals diagonally"
Chet Ramey wrote: Am still on 4.2, but in the bashdir, I get: reset ... ^L Erase is control-H (^H). Kill is control-X (^X). Ishtar:law> hhsfshsdfhl^C Ishtar:law> bind Ishtar:law> cd ../tools/bash/bash-4.3 Ishtar:tools/bash/bash-4.3> ls b bash*bashintl.h bashversion* buildversion.o bashansi.h bashjmp.hbracecomp.c builtins/ bashbug* bashline.c bracecomp.o builtins.h bashhist.c bashline.h braces.c bashhist.h bashline.o braces.o bashhist.o bashtypes.h buildsignames.o Ishtar:tools/bash/bash-4.3> bind 'set print-completions-horizontally on' Ishtar:tools/bash/bash-4.3> ls b bash*bashansi.h bashbug* bashhist.c bashhist.h bashhist.o bashintl.h bashjmp.h bashline.c bashline.h bashline.o bashtypes.h bashversion* bracecomp.c bracecomp.o braces.c braces.o buildsignames.o buildversion.o builtins/ builtins.h --- Yeah, figures it would work right in the BASH dir... BUT... Ishtar:tools/bash/bash-4.3> cd /suse132 --- both of the below print diagonally because they have no line endings. Ishtar:/suse132> ls e17 e17-0.17.6-2.1.10.x86_64.rpm e17-branding-openSUSE-0.1-10.1.2.x86_64.rpm e17-branding-upstream-0.17.6-2.1.10.x86_64.rpm e17-devel-0.17.6-2.1.10.x86_64.rpm e17-doc-html-0.17.6-2.1.10.x86_64.rpm e17-profiles-openSUSE-20131019-2.1.4.noarch.rpm e17-theme-a-os-agust-v3-1-2.1.9.noarch.rpm e17-theme-a-os-detour-1-2.1.9.noarch.rpm e17-theme-a-os-green-1-2.1.9.noarch.rpm e17-theme-a-os-miguel-v3-1-2.1.9.noarch.rpm e17-theme-a-os-vision-v3-1-2.1.9.noarch.rpm e17-theme-darkness-81195-2.1.9.noarch.rpm e17-theme-default-0.17.6-2.1.10.x86_64.rpm e17-theme-edjy-1-2.1.9.noarch.rpm e17-theme-openSUSE-20131101.1-2.1.9.noarch.rpm Ishtar:/suse132> bind 'set print-completions-horizontally' off Ishtar:/suse132> ls e17 e17-0.17.6-2.1.10.x86_64.rpm e17-branding-openSUSE-0.1-10.1.2.x86_64.rpm e17-branding-upstream-0.17.6-2.1.10.x86_64.rpm e17-devel-0.17.6-2.1.10.x86_64.rpm e17-doc-html-0.17.6-2.1.10.x86_64.rpm e17-profiles-openSUSE-20131019-2.1.4.noarch.rpm e17-theme-a-os-agust-v3-1-2.1.9.noarch.rpm e17-theme-a-os-detour-1-2.1.9.noarch.rpm e17-theme-a-os-green-1-2.1.9.noarch.rpm e17-theme-a-os-miguel-v3-1-2.1.9.noarch.rpm e17-theme-a-os-vision-v3-1-2.1.9.noarch.rpm e17-theme-darkness-81195-2.1.9.noarch.rpm e17-theme-default-0.17.6-2.1.10.x86_64.rpm e17-theme-edjy-1-2.1.9.noarch.rpm e17-theme-openSUSE-20131101.1-2.1.9.noarch.rpm
Re: auto-complete going on a diagonal -- "set print-completions-horizontally on => "equals diagonally"
On 7/14/15 3:25 AM, Linda Walsh wrote: > When I go for auto complete now, the filenames no longer line up: > > Ishtar:/suse132> ls e17- > e17-0.17.6-2.1.10.x86_64.rpm > e17-branding-openSUSE-0.1-10.1. > 2.x86_64.rpm e17-branding-upstream-0.17.6-2.1.10.x86_64.rpm > e17-devel-0.1 > 7.6-2.1.10.x86_64.rpm e17-doc-html-0.17.6-2.1.10.x86_64.rpm > e17-profiles-openSUSE-20131019-2.1.4.noarch.rpm > e17-theme-a-os-agust-v3-1- > 2.1.9.noarch.rpm e17-theme-a-os-detour-1-2.1.9.noarch.rpm > e17-them > e-a-os-green-1-2.1.9.noarch.rpm > e17-theme-a-os-miguel-v3-1-2.1.9.noarch > .rpm e17-theme-a-os-vision-v3-1-2.1.9.noarch.rpm > e17-theme-darkness-81 > 195-2.1.9.noarch.rpm > e17-theme-default-0.17.6-2.1.10.x86_64.rpm e17 > -theme-edjy-1-2.1.9.noarch.rpm > e17-theme-openSUSE-20131101.1-2.1. > 9.noarch.rpm > Ishtar:/suse132> ls e17- Your terminal is messed up. Try `reset'. > -- Closest thing was changing the > set print-completions-horizontally to 'on' in .input.rc > > Uhoh, that does affect it, but then the sort order is messed up. The sort order is supposed to change; that's the whole reason for that option. > So how can I get horizontal sorting order without it being all one line? Reset your terminal. When I try this, I get: $ ls b bash bashhist.obashversion.dSYM/ buildsignames.o bashbug bashline.obracecomp.o buildversion.o bashenv bashversion braces.o builtins/ $ bind 'set print-completions-horizontally on' $ ls b bash bashbug bashenv bashhist.o bashline.obashversion bashversion.dSYM/ bracecomp.o braces.o buildsignames.o buildversion.obuiltins/ $ ls b bash bashbug bashenv bashhist.o bashline.obashversion bashversion.dSYM/ bracecomp.o braces.o buildsignames.o buildversion.obuiltins/ on bash-4.4-alpha, hitting TAB after the `b' on each line. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: gcc fails to build w/bash-4.4_alpha
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 7/14/15 8:22 AM, Chet Ramey wrote:
> On 7/14/15 2:33 AM, Mike Frysinger wrote:
>
>> running it with set -x shows that it runs the xgcc & rm steps, but
>> that's
> it.
>> using strace shows xgcc and rm both exit(0), but for some reason
>> bash doe
> s
>> not continue to the following commands like it should.
>
>> if i change the && to a ; after the first rm, it still stops
>> executing at
> that
>> point. if i change the && to a ; after the xgcc command, then the
>> rest o
> f the
>> commands run fine.
>
>> attached is the strace. it is not in fork mode, yet the shell
>> clearly do
> es an
>> exec into the rm tool. looks like bash, for some reason, thinks
>> this is
> the
>> end of the possible commands and so does an optimization to exec
>> into it
> ?
>
> Thanks for the report. That's probably it; I'll take a look.
The following patch removes the code that incorrectly optimizes the fork in
this case. There is a much more direct way to do what I want; that will be
in the next test release.
Chet
- --
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
-BEGIN PGP SIGNATURE-
Version: GnuPG v2
iEYEARECAAYFAlWlC+EACgkQu1hp8GTqdKs+AACgn5NRCw3Hi0oO0ruPrX5F5ijU
nGAAoIV75OFY0KOM/UDLARkV2Q7cyEWd
=QvLq
-END PGP SIGNATURE-
*** ../bash-4.4-alpha/execute_cmd.c 2015-06-12 17:29:18.0 -0400
--- execute_cmd.c 2015-07-14 08:59:22.0 -0400
***
*** 2630,2638
if (ignore_return && second)
second->flags |= CMD_IGNORE_RETURN;
- if (should_suppress_fork (second))
- {
- second->flags |= CMD_NO_FORK;
- second->value.Simple->flags |= CMD_NO_FORK;
- }
exec_result = execute_command (second);
--- 2630,2633
Re: GNU Guile integration
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 7/13/15 4:46 PM, Dmitry Bogatov wrote: > Hello, bug-bash and personally maintainer Chet Ramsey. > > Would you be interested in following patches? > > * GNU Guile integration (built-in that outputs value of Guile procedure >call, similar to what Make recently introduced)? I don't see the value of introducing yet another programming language into bash, which already has one, being more than the cost to do the integration and maintain it. > * Converting build system to use automake? What advantage does this bring over what exists today? Chet - -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/ -BEGIN PGP SIGNATURE- Version: GnuPG v2 iEYEARECAAYFAlWlAxUACgkQu1hp8GTqdKv1egCgkp00KFQS1f4zumKxFAdxlWqt YR4An2uL9DgPBnEBAlWGN5kBgiPRn55t =wBd4 -END PGP SIGNATURE-
Re: gcc fails to build w/bash-4.4_alpha
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 7/14/15 2:33 AM, Mike Frysinger wrote: > running it with set -x shows that it runs the xgcc & rm steps, but that's it. > using strace shows xgcc and rm both exit(0), but for some reason bash doe s > not continue to the following commands like it should. > > if i change the && to a ; after the first rm, it still stops executing at that > point. if i change the && to a ; after the xgcc command, then the rest o f the > commands run fine. > > attached is the strace. it is not in fork mode, yet the shell clearly do es an > exec into the rm tool. looks like bash, for some reason, thinks this is the > end of the possible commands and so does an optimization to exec into it ? Thanks for the report. That's probably it; I'll take a look. Chet - -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/ -BEGIN PGP SIGNATURE- Version: GnuPG v2 iEYEARECAAYFAlWk/wYACgkQu1hp8GTqdKuD3wCfQf5/ktYjfnWQo/QTo/pUPQs2 uoEAn0+D8ZdwwFvznlgppuAIntwoNmPy =YHvf -END PGP SIGNATURE-
general loadable integration
On 14 Jul 2015 11:35, Pierre Gaston wrote: > I think adoption would be difficult considering even a useful loadable > builtin like "finfo" has not found its way into default installations, but > for instance I can imagine bash programmable completion could go another > level with an embedded interpreter that lets you access the readline > internals. finfo is under the "examples" directory, and all of the loadable logic isn't exactly trivial to package. it feels kind of bolted on, especially when you try to build & install things. if we want the loadables to be more of a first class concept than something people only play around with locally on their own systems, this needs polishing. -mike signature.asc Description: Digital signature
Re: GNU Guile integration
On Tue, Jul 14, 2015 at 11:13 AM, Charles Daffern wrote: > On 14/07/15 06:49, Dmitry Bogatov wrote: > > Guile is for situations, when script is mainly calls other programs, > > but still needs moderately complex logic of text manipulation, > > compraison and mapping. Recently I wrote script, that had to emulate > > map(data structure). Well, I would prefer that is was part of Bash. > Bash has associative arrays, which is the data structure other languages > refer to as a map. > > Second (possible) reason is that it allows Bash to be extended by every > > user in Emacs way. After all, Guile was created for this to be possible. > Bash has coproc, which allows 2-way communication with other processes > including scripting language interpreters. (Whether that's a good idea > or not is a different story, but it's possible.) > Bash is a language so sure it can do some kind of things...just not as many things as guile. I think adoption would be difficult considering even a useful loadable builtin like "finfo" has not found its way into default installations, but for instance I can imagine bash programmable completion could go another level with an embedded interpreter that lets you access the readline internals. Other examples could be things like gnu parallel, sqlite3, or parsing xml or json...of course there are external tools for this and you can compile a loadable builtin, but being able to tinker with a small script and having your query result directly into a bash array without further parsing is nice too.
Re: GNU Guile integration
On 14/07/15 06:49, Dmitry Bogatov wrote: > Guile is for situations, when script is mainly calls other programs, > but still needs moderately complex logic of text manipulation, > compraison and mapping. Recently I wrote script, that had to emulate > map(data structure). Well, I would prefer that is was part of Bash. Bash has associative arrays, which is the data structure other languages refer to as a map. > Second (possible) reason is that it allows Bash to be extended by every > user in Emacs way. After all, Guile was created for this to be possible. Bash has coproc, which allows 2-way communication with other processes including scripting language interpreters. (Whether that's a good idea or not is a different story, but it's possible.) signature.asc Description: OpenPGP digital signature
auto-complete going on a diagonal -- "set print-completions-horizontally on => "equals diagonally"
When I go for auto complete now, the filenames no longer line up: Ishtar:/suse132> ls e17- e17-0.17.6-2.1.10.x86_64.rpm e17-branding-openSUSE-0.1-10.1. 2.x86_64.rpm e17-branding-upstream-0.17.6-2.1.10.x86_64.rpm e17-devel-0.1 7.6-2.1.10.x86_64.rpm e17-doc-html-0.17.6-2.1.10.x86_64.rpm e17-profiles-openSUSE-20131019-2.1.4.noarch.rpm e17-theme-a-os-agust-v3-1- 2.1.9.noarch.rpm e17-theme-a-os-detour-1-2.1.9.noarch.rpm e17-them e-a-os-green-1-2.1.9.noarch.rpm e17-theme-a-os-miguel-v3-1-2.1.9.noarch .rpm e17-theme-a-os-vision-v3-1-2.1.9.noarch.rpm e17-theme-darkness-81 195-2.1.9.noarch.rpm e17-theme-default-0.17.6-2.1.10.x86_64.rpm e17 -theme-edjy-1-2.1.9.noarch.rpm e17-theme-openSUSE-20131101.1-2.1. 9.noarch.rpm Ishtar:/suse132> ls e17- --- A bit more investigating, and it looks like it streaming out the filenames with NO LF's (it's all one big long string if I copy it from a window that supports wrapped lines as contiguous -- vs. windows cmd, above. Either way, it's not putting out any line endings. From the number of spaces, it looks like it is thinking my terminal is 98 or 49 spaces wide (i.e. resizing the window makes the names line up at those values). But it doesn't like my old fashion 80-wide term. I'm thinking maybe some library is messed up, since I don't recall changing anything in my bash setup recently. -- Closest thing was changing the set print-completions-horizontally to 'on' in .input.rc Uhoh, that does affect it, but then the sort order is messed up. i.e. ls a f k p u z b g l q v instead of a b c d e f So how can I get horizontal sorting order without it being all one line?
