[PATCH 1/1] Build loadable builtin fltexpr; fix help for history and export
---
builtins/history.def | 3 ++-
builtins/setattr.def | 2 +-
examples/loadables/Makefile.in | 4 ++--
3 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/builtins/history.def b/builtins/history.def
index fa79c0b9..6ce8c8b6 100644
--- a/builtins/history.def
+++ b/builtins/history.def
@@ -23,7 +23,7 @@ $PRODUCES history.c
$BUILTIN history
$FUNCTION history_builtin
$DEPENDS_ON HISTORY
-$SHORT_DOC history [-c] [-d offset] [n] or history -anrw [filename] or history
-ps arg [arg...]
+$SHORT_DOC history [-c] [-d offset] [n] or history -anrw [filename] or history
-ps arg [arg...] or history -d start-end
Display or manipulate the history list.
Display the history list with line numbers, prefixing each modified
@@ -33,6 +33,7 @@ Options:
-c clear the history list by deleting all of the entries
-d offsetdelete the history entry at position OFFSET. Negative
offsets count back from the end of the history list
+ -d start-end delete the history entries from positions START to END
-a append history lines from this session to the history file
-n read all history lines not already read from the history file
diff --git a/builtins/setattr.def b/builtins/setattr.def
index 146b2e0d..7cf9aa9f 100644
--- a/builtins/setattr.def
+++ b/builtins/setattr.def
@@ -59,7 +59,7 @@ executed commands. If VALUE is supplied, assign VALUE before
exporting.
Options:
-f refer to shell functions
-n remove the export property from each NAME
- -p display a list of all exported variables and functions
+ -p display a list of all exported variables
An argument of `--' disables further option processing.
diff --git a/examples/loadables/Makefile.in b/examples/loadables/Makefile.in
index 650628b9..19976b54 100644
--- a/examples/loadables/Makefile.in
+++ b/examples/loadables/Makefile.in
@@ -103,8 +103,8 @@ INC = -I. -I.. -I$(topdir) -I$(topdir)/lib
-I$(topdir)/builtins -I${srcdir} \
ALLPROG = print truefalse sleep finfo logname basename dirname fdflags \
tty pathchk tee head mkdir rmdir mkfifo mktemp printenv id whoami \
uname sync push ln unlink realpath strftime mypid setpgid seq rm \
- accept csv dsv cut stat getconf kv strptime chmod
-OTHERPROG = necho hello cat pushd asort fltexpr
+ accept csv dsv cut stat getconf kv strptime chmod fltexpr
+OTHERPROG = necho hello cat pushd asort
SUBDIRS = perl
--
2.46.3
3 updates for 5.3rc1
Hi, I found the following 3 items. They are addressed by the patch in next email. Patch is against 2e113467f061587a3475b692d25ca449717834c8 in the devel branch. 1. The new fltexpr loadable builtin doesn't get built. Need to move it from OTHERPROG to ALLPROG in Makefile.in. 2. `help export` claims that `export -p` prints exported functions. It does not. 3. `help history` fails to document that you can delete a range. Cheers ... Duncan.
Re: [PATCH 1/1] Build loadable builtin fltexpr; fix help for history and export
On Sun, Apr 06, 2025 at 05:16:18PM +1000, Duncan Roe wrote: > --- > builtins/history.def | 3 ++- > builtins/setattr.def | 2 +- > examples/loadables/Makefile.in | 4 ++-- > 3 files changed, 5 insertions(+), 4 deletions(-) BTW if you like the above patches, save the email to an mbox then `git am` can apply them. Cheers ... Duncan.
Re: ;exit in bash history causes bash to exit
On Tue, Mar 25, 2025 at 05:55:23PM -0400, Greg Wooledge wrote: > On Tue, Mar 25, 2025 at 22:16:15 +0100, microsuxx wrote: > > when bash reads exit cmd it will exit > > so bash reads rc and exits .. > > also .. u may have a ';exit' alias .. > > The claim is that the ;exit appears in .bash_history (not .bashrc) > and that this somehow causes a new instance of bash to exit. > > I doubt anyone will be able to reproduce this. We're almost certainly > going to need more information from Ethan -- the contents of the > relevant dot files, for example. > Easily tested: |$ echo ';exit' >some_file |$ HISTFILE=some_file bash |$ history |1 ;exit No crash in any of the following: 5.2.37(1)-release (x86_64-slackware-linux-gnu) [slackware current] 5.2.32(1)-release (x86_64-redhat-linux-gnu) [fedora 41] 5.2.26(1)-release (x86_64-redhat-linux-gnu) [centos 10] 5.2.21(1)-release (x86_64-pc-cygwin) [cygwin 3.6.0-1.x86_64] Cheers ... Duncan
`help cut` doesn't document what -a does
Hi,
`cut -a ARRAY ...` puts its last line of output in ARRAY[0] and discards any
other elements ARRAY used to have. I tried 3 alternatives:
Alternative A: put last line of output in ARRAY[0] but preserve any other
elements.
Alternative B: empty out the array then put lines of output in successive array
elements.
Alternative C: apply patch A and then patch B so lines are put in successive
elements but if there are less lines than there were elements originally then
preserve those that weren't overwritten.
I have no feeling for which is the most useful, but in any case help should say
what -a does.
Patches are against version 5.3.0(1)-rc2[dbe4256d].
patch-B is not signal-safe, it was just a quick test. arrayind_t ind needs to be
external and zeroed out in the main reading loop.
Cheers ... Duncan.
diff --git a/builtins/common.c b/builtins/common.c
index a681cee4..4628c44f 100644
--- a/builtins/common.c
+++ b/builtins/common.c
@@ -1008,7 +1008,7 @@ builtin_find_indexed_array (char *array_name, int flags)
else if (invisible_p (entry))
VUNSETATTR (entry, att_invisible); /* no longer invisible */
- if (flags & 1)
+ if ((flags & 5) == 1)
array_flush (array_cell (entry));
return entry;
diff --git a/examples/loadables/cut.c b/examples/loadables/cut.c
index b3b8a477..dd0c2c4b 100644
--- a/examples/loadables/cut.c
+++ b/examples/loadables/cut.c
@@ -518,7 +518,7 @@ cut_internal (int which, WORD_LIST *list)
#if defined (ARRAY_VARS)
if (array_name)
{
- v = builtin_find_indexed_array (array_name, 1);
+ v = builtin_find_indexed_array (array_name, 5);
if (v == 0)
{
free (poslist);
@@ -561,7 +561,7 @@ lcut_builtin (WORD_LIST *list)
int
cut_builtin (WORD_LIST *list)
{
- return (cut_internal (1, list));
+ return (cut_internal (5, list));
}
char *lcut_doc[] = {
diff --git a/examples/loadables/cut.c b/examples/loadables/cut.c
index b3b8a477..a7f6024c 100644
--- a/examples/loadables/cut.c
+++ b/examples/loadables/cut.c
@@ -60,6 +60,8 @@ struct cutop
struct cutpos *poslist;
};
+static arrayind_t ind;
+
static int
poscmp (const void *a, const void *b)
{
@@ -145,7 +147,6 @@ getlist (char *arg, struct cutpos **opp)
static int
cutbytes (SHELL_VAR *v, char *line, struct cutop *ops)
{
- arrayind_t ind;
char *buf, *bmap;
size_t llen;
int i, b, n, s, e;
@@ -177,7 +178,6 @@ cutbytes (SHELL_VAR *v, char *line, struct cutop *ops)
if (v)
{
- ind = 0;
#if defined (ARRAY_VARS)
bind_array_element (v, ind, buf, 0);
#endif
@@ -195,7 +195,6 @@ cutbytes (SHELL_VAR *v, char *line, struct cutop *ops)
static int
cutchars (SHELL_VAR *v, char *line, struct cutop *ops)
{
- arrayind_t ind;
char *buf, *bmap;
wchar_t *wbuf, *wb2;
size_t llen, wlen;
@@ -247,7 +246,6 @@ cutchars (SHELL_VAR *v, char *line, struct cutop *ops)
if (v)
{
- ind = 0;
#if defined (ARRAY_VARS)
bind_array_element (v, ind, buf, 0);
#endif
@@ -269,12 +267,10 @@ cutchars (SHELL_VAR *v, char *line, struct cutop *ops)
static int
cutfields (SHELL_VAR *v, char *line, struct cutop *ops)
{
- arrayind_t ind;
char *buf, *bmap, *field, **fields, delim[2];
size_t llen, fsize;
int i, b, n, s, e, nf;
- ind = 0;
delim[0] = ops->delim;
delim[1] = '\0';
@@ -436,6 +432,7 @@ cut_internal (int which, WORD_LIST *list)
struct cutpos *poslist;
v = 0;
+ ind = 0;
rval = EXECUTION_SUCCESS;
cutflags = 0;
Re: `help cut` doesn't document what -a does
On Wed, Jun 04, 2025 at 09:43:00AM -0400, Chet Ramey wrote:
> On 6/2/25 5:58 AM, Duncan Roe wrote:
> > Hi,
> >
> > `cut -a ARRAY ...` puts its last line of output in ARRAY[0] and discards any
> > other elements ARRAY used to have. I tried 3 alternatives:
>
> Thanks for the report. Yes, sometimes marrying the multiple-line-oriented
> output of a tool like `cut' to one-dimensional arrays is awkward.
>
> This has to support output that consists of one field (bytes/chars) or
> multiple fields (well, fields). When you use -f to cut fields, each
> selected field is put into a separate element of the array. When you
> select bytes or characters, the selected bytes get put into array[0] as
> a single field. There's no current way to assign multiple array elements
> when you don't supply -f.
I totally missed that cut -a did that. This reinforces the main point of my
report which was that `help cut` should detail what the -a option does.
>
> The usual behavior of builtins that take array variable names as arguments
> is to unset the array before assigning anything, so I don't see any reason
> to change that. If you want to append to an existing array, there are ways
> to do that with array `cut' populates.
>
> I think the bigger issue is your alternative B: how to handle multiple
> lines of output with a single one-dimensional array.
>
> > Alternative B: empty out the array then put lines of output in successive
> > array elements.
>
> Is it useful to combine multiple selected fields (-f) into one space-
> separated field so `cut' can put the selected portions of each line into
> a corresponding array element?
I'm inclined to think not. Because, what if a field itself contains spaces?
The main thing is to document -a. I've attached a sample patch.
Cheers ... Duncan.
diff --git a/examples/loadables/cut.c b/examples/loadables/cut.c
index b3b8a477..6ac3cd8f 100644
--- a/examples/loadables/cut.c
+++ b/examples/loadables/cut.c
@@ -603,6 +603,10 @@ char *cut_doc[] = {
"Columns correspond to bytes (-b), characters (-c), or fields (-f).
The",
"field delimiter is specified by -d (default TAB). Column numbering",
"starts at 1.",
+ "",
+ "-a places the last line output by cut in the indexed array ARRAY.",
+ "-f fields are assigned to elements of ARRAY starting at index 0",
+ "otherwise ARRAY[0] holds the entire line.",
(char *)NULL
};
lcut query
Hi Chet,
`help lcut` implies to me that columns specified -b or -c should go to
separate elements of ARRAY (unlike what cut does), but they do not.
| 20:20:34$ lcut -a i -c1,2,3 abc
| 20:30:13$ echo ${i[0]}
| abc
| 20:30:23$ echo ${i[1]}
|
| 20:30:42$
Cheers ... Duncan.
[ PATCH ] NEWS: Make it clear that fltexpr is a *loadable* builtin
Hi NEWS announces the new fltexpr builtin but doesn't mention you have to enable it. BTW, fltexpr is so much closer to let than to expr, wouldn't it be better called letflt? (Not fltlet - that sounds like a baby flt :) Cheers ... Duncan. diff --git a/NEWS b/NEWS index 2107abef..e2f9cc7b 100644 --- a/NEWS +++ b/NEWS @@ -143,8 +143,8 @@ uu. If `exit' is run in a trap and not supplied an exit status argument, it `top level' and would cause the trap to end (that is, not in a subshell). This is from Posix interp 1602. -vv. There is a new `fltexpr' builtin to perform floating-point arithmetic -similarly to `let'. +vv. There is a new `fltexpr' loadable builtin to perform floating-point +arithmetic similarly to `let'. ww. The `install-strip' and `strip' Makefile targets now deal with cross- compiling.
Re: `help cut` doesn't document what -a does
On Thu, Jun 05, 2025 at 11:12:43PM -0400, Greg Wooledge wrote: > On Fri, Jun 06, 2025 at 12:55:34 +1000, Duncan Roe wrote: > > On Thu, Jun 05, 2025 at 06:55:55AM -0400, Greg Wooledge wrote: > > > On Thu, Jun 05, 2025 at 12:34:44 +0200, microsuxx wrote: > > > > i installed bash dev , but there is no `help cut` > > > > > > It's a "loadable builtin". You have to build those, install them, > > > and then load the "cut" builtin explicitly. > > > > > `make install` does put the binaries in /usr/lib/bash, but not all > > distributions > > publish /usr/lib/bash. It's an optional extra in Debian / Ubuntu: see > > https://bugzilla.redhat.com/show_bug.cgi?id=2369713 (scroll to read the > > description). > > I don't know why I would read a redhat.com web page to learn about > Debian or Ubuntu. I'm aware that there's a "bash-builtins" package > in Debian which provides them (for Debian's version of bash). If you had followed the link you would have found out why (it's my bug report). > > However, xmb's question was about "bash dev", which I'm reading as > "bash compiled from source code". If one is building bash from source, > then the loadable builtins would also need to be built and installed > before they can be used. > If one is building bash from source, then (most of) the loadable builtins are built and installed (at least since bash 4.4). Cheers ... Duncan.
Re: `help cut` doesn't document what -a does
On Thu, Jun 05, 2025 at 06:55:55AM -0400, Greg Wooledge wrote: > On Thu, Jun 05, 2025 at 12:34:44 +0200, microsuxx wrote: > > i installed bash dev , but there is no `help cut` > > It's a "loadable builtin". You have to build those, install them, > and then load the "cut" builtin explicitly. > `make install` does put the binaries in /usr/lib/bash, but not all distributions publish /usr/lib/bash. It's an optional extra in Debian / Ubuntu: see https://bugzilla.redhat.com/show_bug.cgi?id=2369713 (scroll to read the description). Cheers ... Duncan.
Re: lcut query
On Thu, Jun 05, 2025 at 01:39:24PM -0400, Chet Ramey wrote: > On 6/5/25 10:27 AM, Chet Ramey wrote: > > On 6/5/25 6:41 AM, Duncan Roe wrote: > > > Hi Chet, > > > > > > `help lcut` implies to me that columns specified -b or -c should go to > > > separate elements of ARRAY (unlike what cut does), but they do not. > > > > Thanks, I'll take a look. I haven't played with `lcut' in a long time; > > that's why it's not in the makefile. > > Or are you talking about the lcut that's included in cut.c? cut and lcut > behave the same way; they use the same code. > Yes, I loaded it with `enable -f cut lcut` using 5.3.0(1)-rc2. So, it's a documentation error in the lcut that's included in cut.c? I like it anyway, BTW. Cheers ... Duncan.
Re: Meta: `help cut` doesn't document what -a does
On Wed, Jun 11, 2025 at 10:38:17AM -0400, Chet Ramey wrote: > The business of installing the loadables and > headers on `make install' came later as the result of feature requests. > Fine for `make install' to *install* them. But it flies in the face of convention for `make install' to *build* them - `make' should do that. Cheers ... Duncan.
Re: Meta: `help cut` doesn't document what -a does
On Fri, Jun 06, 2025 at 10:27:56AM -0400, Chet Ramey wrote: > > They're always built and installed when you use `make install'. The > problem, of course, is users (some) or distros (all) who don't use a ^^^ Slackware does > simple `make install', but rather some other installation or packaging > mechanism. > Wouldn't it be a lot easier for everyone if `make` compiled the supported examples instead of `make install` doing it? Can we have this in 5.3 please? Cheers ... Duncan.
