Re: [sr #111058] Problem transmitting script arguments

"Kerin Millar" writes: > On Mon, 6 May 2024, at 7:01 PM, Dale R. Worley wrote: >> anonymous writes: >>> [...] > It's likely that your reply will never be seen by the anonymous > Savannah issue filer. OK. Now does that mean that there is no way for me to effe

Re: [sr #111058] Problem transmitting script arguments

anonymous writes: > URL: > > > Summary: Problem transmitting script arguments > Date: Sat 04 May 2024 10:08:41 AM UTC By: Anonymous > I have the following problem with transmitting arguments to a bash script > onward to an inside

Re: [PATCH 0/4] Add import builtin

It seems like you could get much the same effect with this device: -- t1 contains: # Where I am doing this testing. BASH_IMPORT_PATH=$HOME/temp/import/t2 echo "Note PATH does not contain '.'" echo "PATH=$PATH" echo

Re: Scope change in loops with "read" built-in

"Linde, Evan" writes: > In a loop constructed like `... | while read ...`, changes to > variables declared outside the loop only have a loop local > scope, unlike other "while" or "for" loops. Yeah, that's a gotcha. But it's a general feature of *pipelines*, documented in Each command

Re: feat: exit 1 "file not found"

teknopaul writes: > Hi not sure if this is the correct forum... I believe this is the correct forum. > exit builtin accepts one and only one arg currently. > > Would it be backwards compatible and generally useful to support > echoing a reason for exiting? > > test -f file || exit 2 "file not

Re: human-friendly ulimit values?

Christian Convey writes: > When setting memory-size limits via "ulimits", users have to manually > convert from their intuitive units. > > E.g., for limiting virtual memory to 8 gigabytes, the invocation is "ulimit > -v 8388608", rather than something like "ulimit -v 8gb". > > If I were to submit

Re: Slow history load with some values of HISTSIZE

Casey Johnson writes: > In a clean shell, execute: > HISTFILE=alt-history.txt > HISTSIZE=15 > history -r > and then observe how long the last command runs before returning. Though I expect that when you exit bash, the history file gets trimmed to

Re: wait -n misses signaled subprocess

Chet Ramey writes: >> echo "wait -n $pid return code $? @${SECONDS} (BUG)" > > The job isn't in the jobs table because you've already been notified about > it and it's not `new', you get the unknown job error status. The man page gives a lot of details and I'm trying to digest them into a

Re: wait -n misses signaled subprocess

Steven Pelley writes: > wait -n > fails to return for processes that terminate due to a signal prior to > calling wait -n. Instead, it returns 127 with an error that the > process id cannot be found. Calling wait (without -n) then > returns its exit code (e.g., 143). My understanding is that

Re: completion very slow with gigantic list

Eric Wong writes: > Hi, I noticed bash struggles with gigantic completion lists > (100k items of ~70 chars each) A priori, it isn't surprising. But the question becomes "What algorithmic improvement to bash would make this work faster?" and then "Who will write this code?" Dale

Re: Unexpected Quick Substitution in string literals

Chet Ramey writes: >> While declaring a string literal across multiple lines, a line starting >> with the ^ character is resulting in some sort of quick substitution >> processing. > > This is a standard form of history expansion, described in the man page. I just checked. Certainly, the use of

Re: Regex: A case where the longest match isn't being found

"Dan Bornstein" writes: > I found a case where the regex evaluator doesn't seem to be finding > the longest possible match for a given expression. The expression > works as expected on an older version of Bash (3.2.57(1)-release > (arm64-apple-darwin22)). > > Here's the regex:

Handling of SIGHUP

The basic explanation of how Bash handles SIGUP is (in 5.1): The shell exits by default upon receipt of a SIGHUP. Before exiting, an interactive shell resends the SIGHUP to all jobs, running or stopped. Stopped jobs are sent SIGCONT to ensure that they receive the

Re: variable set in exec'ing shell cannot be unset by child shell

Ti Strga writes: > The summary is that if a parameter is set specifically for a '.'/'source' > command, and the source'd file calls 'exec' to run another script, then > that exec'd script cannot unset the parameter; if we want that parameter > to not be present in the exec'd script, then the

Re: using exec to close a fd in a var crashes bash

Is there any way to write a redirection "Redirect the fd whose number is in $FOO to file /foo/bar?" OK, you can write 'bash -c "..."' and assemble a command string however you want. But is there a direct way to write it? The "{var}>..." mechanism *assigns* to $var, rather than taking its

Re: ! history expansion occurs within arithmetic substitutions

Andreas Schwab writes: >> More troublesome, I think, are several variable substitutions which >> include "!" followed by a name. But I doubt they're used much in >> interactive mode. > > The history expansion is smart enough to not interfere with ${!var}. Yes... Also, the same magic seems to

Re: ! history expansion occurs within arithmetic substitutions

Zachary Santer writes: > When messing around in interactive mode to test things I may want to do in > a script, it's nice if it actually behaves the same. There are probably > some other set and possibly shopt things I should have somewhere if that's > what I want. I checked, and it doesn't seem

Re: !; is interpreted as an history expansion that can never match anything

Emanuele Torre writes: > ! followed by a ; or another terminator is interpreted as an history > expansion with no pattern that can never match anything. > > $ !; echo hi > bash: !: event not found > $ !&& echo hi > bash: !: event not found IMHO it is more to the point that in the manual

Re: ! history expansion occurs within arithmetic substitutions

Zachary Santer writes: > Description: > Similarly, history expansion occurs within arithmetic substitutions. This > will never, ever be what the user wants. And now I know how to make it not > happen. > > Repeat-By: > $ set +o histexpand Well, yes, if you turn off history expansion, then it

Re: comments inside command subst are handled inconsistently

Denys Vlasenko writes: > Try these two commands: > > $ echo "Date: `date #comment`" > Date: Thu Jul 27 10:28:13 CEST 2023 > > $ echo "Date: $(date #comment)" >> )" > Date: Thu Jul 27 10:27:58 CEST 2023 > > As you see, #comment is handled differently in `` and $(). > I think the handling in ``

Re: git amend commit with backticks on cli causes tty to crash

Wiley Young writes: > I'm seeing this behavior on Fedora 38. Possibly it's just some user error > again, since i'm figuring out how to use vim and git at a slightly above > novice level. :-) Well, I think I can get an idea of what you're doing. I'm not sure, you really want to create a

Re: nofork command substitution

Chet Ramey writes: > Bash allows the close brace to be joined to the remaining > characters in the word without being followed by a shell metacharacter > as a reserved word would usually require. I had to read this a couple of times to figure out what it means. In particular "the word" isn't

Re: nofork command substitution

Ángel writes: > I suggest: > >> There is an alternate form of command substitution: >> >> ${ COMMAND; } > > and clarify later the other variants in addition to a space: > >> The character following the open brace must be a space, tab, >> newline, '(', or '|', and the close brace must

Re: How difficult would it be to add a timeout to "wait"?

Chet Ramey writes: > On 4/20/23 1:53 PM, Dale R. Worley wrote: >> How difficult would it be to add an optional timeout argument to the >> "wait" builtin? > > Try a variant of this. > ... My interest here isn't "Can I accomplish this task with

How difficult would it be to add a timeout to "wait"?

How difficult would it be to add an optional timeout argument to the "wait" builtin? I occasionally run into situations where this functionality is desirable, more often than I expect, really. And though the last thing Bash needs is an additional feature, naively it seems like it wouldn't be too

Re: Document that here strings don't support brace expansion.

Chet Ramey writes: > If they're linked, why wouldn't saying filename generation isn't performed > be enough to imply that brace expansion isn't performed either? Hmm, yes, good point. Dale

Re: Document that here strings don't support brace expansion.

Alex Bochannek writes: > "The WORD undergoes tilde expansion, parameter and variable expansion, > command substitution, arithmetic expansion, and quote removal. Filename > expansion and word splitting are not performed." > > It is missing brace expansion, which is not supported: Interesting ...

Re: The memory occupied by bash has been increasing due to the fork bomb

zju <21625...@zju.edu.cn> writes: >> Interactive shells always ignore SIGTERM. > > I confirmed that the fork bomb through bash would cause the system > oom! This indicates that anybody can use this flaw to crash the > system.It is quite dangerous. > > If you think the behavior of ignoring the

Re: Having an alias and a function with the same name leads to some sort of recursion

Chet Ramey writes: > On 2/14/23 2:58 PM, Dale R. Worley wrote: >>>> Looking at the manual page, it says >>>> >>>> ALIASES >>>> Aliases allow a string to be substituted for a word when it is >>>> used as >>&

Re: Having an alias and a function with the same name leads to some sort of recursion

>> Looking at the manual page, it says >> >> ALIASES >>Aliases allow a string to be substituted for a word when it is used >> as >>the first word of a simple command. Martin suggested (but IIUC didn't sent to this list): > "Beginning of a simple command" should probably be

Re: number of bugs

There is a bug tracker at https://savannah.gnu.org/support/?group=bash. Dale

Re: "builtin jobs" does not output to stdout.

Chet Ramey writes: > Yes. As described in later messages, there is a special case that allows > the output of `jobs' to be piped. This came in at some point between > bash-1.05 (March 1990) and bash-1.08 (May 1991). I never extended this > special case to `builtin' or `command'. Is this (are

Re: Having an alias and a function with the same name leads to some sort of recursion

Robert Elz writes: > | Aliases are not used in bash scripts, unless bash is invoked in POSIX > | compatibility mode, or the "expand_aliases" shopt is turned on. > > I think that's what must have happened ... the infinite loop of > echo commands suggests that the function definition > >

Re: [PATCH] local_builtin: do not overwrite previously saved options with local -

This is tricky. The documentation is If NAME is '-', the set of shell options is made local to the function in which 'local' is invoked: shell options changed using the 'set' builtin inside the function are restored to their original values when the function returns. It does

Re: unset does not remove functions like a[b] unless -f is specified

Greg Wooledge writes: > I'd be totally OK with restricting the function namespace a bit more. > Function names should not be allowed to contain backticks or less-than > or greater-than signs (in my opinion). I'm still undecided about > parentheses, but I'm leaning toward "denied". I'd be

Re: unset does not remove functions like a[b] unless -f is specified

Emanuele Torre writes: > bash-5.1$ a[0] () { echo;} > bash-5.1$ unset 'a[0]' Admittedly, I'm running Bash 5.1.0, but the manual page says: fname () compound-command [redirection] function fname [()] compound-command [redirection] ...in posix mode, fname must

Re: More convenient tracing

Greg Wooledge writes: > On Wed, Jan 25, 2023 at 03:00:27PM -0500, Dale R. Worley wrote: >> >> Tracing with -x prints a lot of (usually) useless lines. >> >> $ bash -x ./tt >> [300+ lines of Bash initializations] >> + echo 'Now in tt.' >>

More convenient tracing

Some time ago I proposed a new option to Bash to cause it to trace commands (in the manner of -x) but not within the Bash initialization scripts. People advised me that this could be accomplished without a new option. I also picked up various suggestions for how to design it. This is my latest

Re: Possible bug in bash

Greg Wooledge writes: > On Fri, May 13, 2022 at 10:36:56PM -0400, Dale R. Worley wrote: >> Reading your message, I believe that the rule can be stated as follows, >> and I'd thank you to check it: && and || have the same precedence, and >> they both "associa

Re: `declare -f "a="' fails unnecessarily

Andreas Schwab writes: >> In default mode, you actually can do >> $ function a=b { printf hi\\n; } >> though you can't execute it: >> $ a=b foo >> bash: foo: command not found > > You just have to quote any part of the function name upto the equal sign > to stop if from being

Re: `declare -f "a="' fails unnecessarily

Emanuele Torre writes: > `declare -f "something="' fails with the following error: > > $ declare -f 'a=x' > bash: declare: cannot use `-f' to make functions > That error is not very useful. Bash makes `declare -f' fail with that > error when an argument looks like an assignment. It's an

Re: declare XXX=$(false);echo $?

Chet Ramey writes: > On 12/2/22 5:28 AM, Ulrich Windl wrote: >> Surprisingly "declare XXX=$(false);echo $?" outputs "0" (not "1") >> There is no indication in the manual page that "declare" ignores the >exit code of commands being executed to set values. > > Why do you think it should? `declare'

Re: Bad leaks file fd to child processes

Greg Wooledge writes: > The fact that pvs *complains* about this instead of just ignoring it makes > it fairly unique. I don't know why the authors of pvs chose to do this. > Perhaps they were working around some known or suspected bug in some other > program that was commonly used as pvs's

Re: Bad leaks file fd to child processes

Alexey via Bug reports for the GNU Bourne Again SHell > Same behavior was in bash 4.4 (as well as now in bash 5.2): > > # echo $BASH_VERSION > 4.4.0(1)-release > # exec 66 # pvs > File descriptor 66 (/etc/hosts) leaked on pvs invocation. Parent PID > 1057606: ./bash > > But we use the fact tat

Re: Bad leaks file fd to child processes

"凋叶棕" via Bug reports for the GNU Bourne Again SHell writes: > I find that the file descriptor leaks when I execute the command pvs > in bash 5.2, The abnormal scenario is similar to the bug which > reported by > http://lists.gnu.org/archive/html/bug-bash/2017-01/msg00026.html > > When I

Re: feature request: new builtin `defer`, scope delayed eval

The Go programming language has a "defer" statement which is used considerably for exactly this purpose. So we know that it's useful in practice. The question remains what is a good way to introduce it into Bash. As others have noted, there is already a "trap" with similar functionality. I'm

Re: Found Bug and generated report using Bashbug

Chet Ramey writes: > On 9/5/22 6:13 PM, Aryan Bansal wrote: > >While testing how bash handles foreground and background processes > >using "&", I found out that the behaviour is sometimes undefined. The > >prompt sometimes prints just as the background process finishes executing >

Re: test or [ does not handle parentheses as stated in manpage

Julian Gilbey writes: > Upgrading to bash 5.2.0(1)-rc2 did not help, neither did using \( > instead of (, and neither did putting spaces around the parentheses. It's ugly. The first point is that ( and ) are special characters and if unquoted are isolated tokens that have special syntax. So in

Re: Light weight support for JSON

Greg Wooledge writes: > The standard idiom for this sort of thing is > > eval "$(external-tool)" > > This means you need to *trust* the external-tool to produce safe code. True. And I use that idiom with ssh-agent routinely. But it still strikes me as unnatural. Dale

Re: Light weight support for JSON

The "obvious" way to support Json in Bash would be a utility that parses Json and produces e.g. a Bash associative array, and conversely a utility that reads a Bash associative array and produces Json. The real limitation is that it's difficult to have a subprocess set Bash's variables. As far

Re: add custom environment variable in bash source code

Sam writes: > You probably want to edit /etc/ld.so.conf or /etc/ld.so.conf.d/* instead. The overall concept is that you almost certainly don't want to modify the bash source code (and thus executable) to do this. In general, if you want to have a particular environment variable set "all the

Re: local -r issue in conjunction with trap

Robert Stoll writes: > test1 # works as exit happens outside of test1 > test2 # fails with ./src/test.sh: line 6: local: readonlyVar: readonly > variable Beware that you haven't specified what you mean by "works" and "fails". I assume from the context that "fails" means "produces an error

Re: Gettings LINES and COLUMNS from stderr instead of /dev/tty

Martin Schulte writes: > I'm just wondering that bash (reproduced with 5.2-rc1 under Debian 11) > seems to determine LINES and COLUMNS from stderr. It's not clear to me that the manual page says where the LINES and COLUMNS values are obtained from. Dale

Re: Arithmetic expression: interest in unsigned right shift?

Steffen Nurpmeso writes: > I realized there is no unsigned right shift in bash arithmetic > expression, and thought maybe there is interest. This would be difficult to define cleanly. Currently, arithmetic values are considered to be signed, and >> operates on them as such. So $ echo $((

Re: Parallelization of shell scripts for 'configure' etc.

Paul Eggert writes: > In many Gnu projects, the 'configure' script is the biggest barrier to > building because it takes s long to run. Is there some way that we > could improve its performance without completely reengineering it, by > improving Bash so that it can parallelize 'configure'

Re: Unfortunate error message for invalid executable

AA via Bug reports for the GNU Bourne Again SHell writes: > I.e., something like "I'm not sure what's going on, but your path > definitely exists, yet the kernel says otherwise." > > ... something like fprintf(STDERR,"No such file or directory while > attempting to execute %s (it exists, but

Re: Unfortunate error message for invalid executable

Chet Ramey writes: > On 5/26/22 2:27 PM, AA via Bug reports for the GNU Bourne Again SHell wrote: >> When a user attempts to execute an executable that is not >> recognized as an executable by the system, the generated error is "No such >> file or directory" > > In this case, it's the errno

Re: Possible bug in bash

Robert Elz writes: > Note particularly that there is no operator precedence between > && and || - they are the same (unlike in C for example) Reading your message, I believe that the rule can be stated as follows, and I'd thank you to check it: && and || have the same precedence, and they both

Re: bash 5.1 heredoc pipes problematic, shopt needed

Sam Liddicott writes: > Listed in the changes: > c. Here documents and here strings now use pipes for the expanded >document if it's smaller than the pipe buffer size, reverting >to temporary files if it's larger. > > This causes problems with many

Re: Bash regexp parsing would benefit from safe recursion limit

willi1337 bald writes: > A deeply nested and incorrect regex expression can cause exhaustion of > stack resources, which crashes the bash process. Further, you could construct a deeply nested regex that is correct but would still crash the process. It's hard to define what should happen in a

Re: Sus behaviour when cmd string ends with single backslash

vzvz...@gmail.com writes: > The mentioned bug is indeed fixed by this change. However, in case of > another edge case following new behaviour is observable: > > $ bash -c 'echo \' > \ > $ # backslash appears on output It's an interesting case, since the command that Bash is executing is

Re: Zero-length indexed arrays

Lawrence Velázquez writes: > Did you mean to say that ${#FOO[*]} causes an error? Because > ${FOO[*]} does not, a la $*: The case that matters for me is the Bash that ships with "Oracle Linux". Which turns out to be version 4.2.46(2) from 2011, which is a lot older than I would expect. But it

Zero-length indexed arrays

A bit ago I was debugging a failing script at work. It turns out that when you say FOO=(x y z) then the variable FOO is an array and is defined. But when you say FOO=() then the variable FOO is an array (because ${#FOO[*]} substitutes an integer viz. 0) but it is *not* defined (because

Re: some.. bug .. ?

Alex fxmbsw7 Ratchev writes: > printf 'e=. ; (( $# > 1 )) && $e afile "${@:1:$# -1}"' >afile ; . afile 1 2 > 3 > > bash: : command not found This looks like another instance where you've constructed a command whose first word is the empty word. Try running with "set -x" and see what the command

Re: read -t0 may report that input is available where none is possible

More to the essence: $ read -t0

Re: coproc does not work with a lower case variable name

g...@as.lan writes: > Description: > coproc gives a syntax error if I try to use it with a lower case > variable name and a compound command: > bash: syntax error near unexpected token `}' > bash: syntax error near unexpected token `(' > > Repeat-By: > coproc bc { bc; } >

Re: bash conditional expressions

Mischa Baars writes: > Using Fedora 32 (bash 5.0.17) this returns a true, while on Fedora 35 (bash > 5.1.8) this returns a false: > touch test; if [[ -N test ]]; then echo true; else echo false; fi; Well, looking at the manual page, I see -N file True if file exists

Re: cmd completion.. normal that it doesnt complete dirs when cmds are available ?

Alex fxmbsw7 Ratchev writes: > i have a dir with some xbl*/ dirs and few xbl* commands ( via $PATH ) > i tried there xbl,tabtab but it only completed cmds > is this desired ? Naively, I would expect that when doing completion in the first position in a command, that the completion process will

Re: Why should `break' and `continue' in functions not break loops running outside of the function?

Oğuz writes: >> It's a violation of scope. > > It's a violation of lexical scope, I'm asking why not implement > dynamic scope, what's wrong with it? Yes ... but the history of programming languages has been the history of learning that dynamic scoping is dangerous to program and lexical

Re: Arbitrary command execution from test on a quoted string

elettrino via Bug reports for the GNU Bourne Again SHell writes: > The following shows an example of bash testing a quoted string and as > a result executing a command embedded in the string. > > Here I used the command "id" to stand as an example of a command. The > output of id on this machine

Re: bash support for XDG Base Directory spec (~/.config/bash/)

Using XDG will have the complication that one normally sets environment variables like XDG_CONFIG_DIRS in ~/.bash_login. So I would add to the conversation, How much added value is there if XDG_CONFIG_DIRS is not used in practice? Dale

Re: ?maybe? RFE?... read -h ?

L A Walsh writes: > I know how -h can detect a symlink, but I was wondering, is > there a way for bash to know where the symlink points (without > using an external program)? My understanding is that it has been convention to use the "readlink" program for a very long time, so there's never been

Re: Interactive commands cant be backgrounded if run from bashrc

"C. Yang" writes: > This may be because the bashrc file is still running, and bash itself > perhaps does not finish initializing until everything in the bashrc > completes. This may be why CTRL+Z does not work correctly (it might > require bash to finish initializing first) I'm sure that's the

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

Hyunho Cho writes: > If i enter a command line like below then '>' prompt appears for the > input of here document. > > bash$ { cat <<\@ > foo ;} 2> /dev/null >> 111 >> 222 # '>' prompt >> @ > > > but if i use alias then '>' prompt does not appear and default bash > prompt

Re: Defect in manual section "Conditional Constructs" / case

"Dietmar P. Schindler" writes: > Doesn't the example I gave above show that quotes are removed? If they > weren't, how could word aa with pattern a""a constitute a match? As you say, >a""a< matches as a case-pattern when the case word is >aa<. But that's not due to quote removal, because what

Re: GROUPS

Robert Elz writes: > | What seems to be the case with sh-style shells and Posix is that > | all-caps variable names are subject to implementation-specific use, and > | so users should not use them except when using them in the way that is > | specific to the implementation the script is

Re: RFE: new option affecting * expansion

"Chris F.A. Johnson" writes: > It would be nice if there were an option to allow * to expand sorted > by timestamp rather than aphabetically. Generally, a new option is not a good way to accomplish this, as an option has global effects and can cause other parts of the code to malfunction. Back

Re: GROUPS

It seems to me that people are avoiding both the core issue and its solution. A standard is what allows people to write software that can be ported without having to reassess every detail of the program. To take C as an example, the standard defines what identifiers look like, which identifiers

Re: Crash on large brace expansion

Gabríel Arthúr Pétursson writes: > Executing the following results in a fierce crash: > >$ bash -c '{0..255}.{0..255}.{0..255}.{0..255}' >malloc(): unaligned fastbin chunk detected 2 >Aborted (core dumped) As others have noted, you are attempting to construct 2^32 words. Now it's

Re: 'wait' in command group in pipeline fails to recognize child process

> It's not the brace command; it's the pipeline. > >> Minimal repro: >> >>$ sleep 1 & { wait $!; } | cat >>[1] 665454 >>bash: wait: pid 665454 is not a child of this shell Interestingly, this is almost trivial to clairfy: $ sleep 5 & { wait $!; } [1] 19069 [1]+ Done

Re: `&>' doesn't behave as expected in POSIX mode

Oğuz writes: > $ set -o posix > $ uname &>/dev/null > $ > > `uname &' and `>/dev/null' should be parsed as two separate commands; > that, if I'm not missing anything, is what POSIX says. But bash > doesn't do that in POSIX mode, and redirects both stderr and stdout to > `/dev/null'.

Re: [patch #10070] toggle invert flag when reading `!'

>> >[[ ! 1 -eq 1 ]]; echo $? >> >[[ ! ! 1 -eq 1 ]]; echo $? >> > >> > would both result in `1', since parsing `!' set CMD_INVERT_RETURN >> > instead of toggling it. Definitely, the section of the man page for "[[" says that "!" is a negation operator, so "! ! foo" must yield the same

Re: select syntax violates the POLA

Robert Elz writes: > You're assuming that the manual is a precise specification of what > is allowed. Um, of course. "The documentation is the contract between the user and the implementer." If something undocumented happens to work, there is no requirement on the implementer to maintain its

Re: select syntax violates the POLA

Robert Elz writes: > From:wor...@alum.mit.edu (Dale R. Worley) > > | I was going to ask why "else {" works, > > The right question would be why '} else' works. Yeah, typo on my part. The manual page says if list; then list; [ elif list; then list

Re: select syntax violates the POLA

Chet Ramey writes: > Yes, you need a list terminator so that `done' is recognized as a reserved > word here. `;' is sufficient. Select doesn't allow the `done' unless it's > in a command position. Some of the other compound commands have special > cases, mostly inherited from the Bourne shell, to

Re: select syntax violates the POLA

Greg Wooledge writes: > It's amazing how many people manage to post their code with NO comments > or explanations of what it's supposed to do, what assumptions are being > made about the inputs, etc. This leaves us to guess. It seems to be a modern style. When I was learning to program, poorly

Re: missing way to extract data out of data

Andreas Schwab writes: >> I've never tracked down why, but the Perl executable is a lot smaller >> than the Bash executable. > > Is it? > > $ size /usr/bin/perl /bin/bash >textdata bss dec hex filename > 2068661 27364 648 2096673 1ffe21 /usr/bin/perl > 1056850 22188

Re: how does ssh cause this loop to preterminate?

Eduardo Bustamante writes: > The summary is that SSH is reading from the same file descriptor as > "read". Use '-n' (or redirect SSH's stdin from /dev/null) to prevent > this. Oh, yeah, I've been bitten by that one many times. Another solution, though more awkward, is feeding the data for read

Re: Wanted: quoted param expansion that expands to nothing if no params

L A Walsh writes: > It would be nice to have a expansion that preserves arg boundaries > but that expands to nothing when there are 0 parameters > (because whatever gets called still sees "" as a parameter) Fiddling a bit, I found this is a nice way to show how "$@" (or any other construction)

Re: missing way to extract data out of data

Greg Wooledge writes: > Partly true. seq(1) is a Linux thing, and was never part of any > tradition, until Linux people started doing it. Huh. I started with Ultrix, and then SunOS, but don't remember learning seq at a later date. > (Before POSIX, it involved using expr(1) for every

Re: about the local not-on-every-function-separately var issue

Greg Wooledge writes: > Now, the big question is WHY you thought something which is not correct. > > The most common reasons that people think something which is wrong are: In my experience, a common reason is that the documentation does not concentrate in one place that users are certain to

Re: missing way to extract data out of data

Alex fxmbsw7 Ratchev writes: > yea well it does wonders, however was looking for a way without spawning > externals like gawk.. maybe in future there will be =) Traditionally, shell scripts depended on external binaries to do a lot of the processing. At the least, what newer shells do with

Re: Likely Bash bug

Jay via Bug reports for the GNU Bourne Again SHell writes: > I have no idea what the "ash" the bug report refers to > is (there is an ancient shell of that name, but I cannot imagine any > distribution including that, instead of one of its bug fixed and updated > successors, like say, dash)

Re: Probably not a bug but I was surprised: $' does not work inside "..." close.

Greg Wooledge writes: > $'...' is a form of quoting, not an expansion. It won't "work" inside > of another type of quoting, just like '...' will not "work" inside "...". Yes, that's true, and makes sense when I think about it. But the manual page doesn't consistently phrase it that way:

Re: missing way to extract data out of data

Alex fxmbsw7 Ratchev writes: > there is way to crop data to wanted, by cropping the exclulsions away > but what about a way to extract data, eg @( .. ) match > not about using [[ =~ but only var internal stuff > .. or do i miss there something If you want to do a pattern-match against a string,

Probably not a bug but I was surprised: $' does not work inside "..." close.

I have it encoded in my head that $ inside "..." is respected. Subtly, the $'...' construction is not respected inside "...". After reading the manual page carefully, I realized this is because the interpretation of $'...' is not part of parameter expansion (despite its $) but rather it is a

Re: 'exec' produced internal code output instead of normal

> 2021年3月13日(土) 8:06 Alex fxmbsw7 Ratchev : >> but using it resulted sometimes output of code of the script in the output >> of the files >> removing exec made it work normally as supposed One possibility is a typo, using "<<" rather than "<". Koichi Murase writes: > I don't know about `socat',

Re: Shell Grammar man page function definition

Mike Jonkmans writes: > Some examples that work: > function x { :; } ## as expected > function x if :; then :; fi > function x (( 42 )) > function x [[ 42 ]] > function x for x do :; done > function x for (( ; 42 - 42 ; )); do :; done > > What does not work: >

Re: syntax error while parsing a case command within `$(...)'

Lawrence Velázquez writes: >>> `;;' is optional for the last case item. >> >> The manual page (for my version) says it's required. If, in some >> certain circumstances, it works without, that's nice. > > It's also required by POSIX. Ah, now that's different. Has the current man page been

Re: syntax error while parsing a case command within `$(...)'

Oğuz writes: >> Before we worry about what to change, I want to note that the original >> example is syntactically incorrect. The example is >> >> $ bash -c ': $(case x in x) esac)' >> >> But the manual page makes it clear that each case must be ended with >> ";;". > > `;;' is optional for the

  1   2   >