Re: Sourcing a script from a pipe is not reliable

Date:Thu, 10 Jan 2019 13:52:59 -0800 From:Jeremy Message-ID: | We are trying to determine if the current shell supports passing positional | arguments to a script sourced by dot (.), and we are trying to do it in a | way that will work under pretty much any

Re: "return" should not continue script execution, even if used inappropriately

Date:Mon, 7 Jan 2019 08:55:58 -0500 From:Greg Wooledge Message-ID: <20190107135558.reqhfhr5vy3ih...@eeg.ccf.org> | https://mywiki.wooledge.org/BashFAQ/109 Which only works when the shell is bash... df...@dfong.com said: | there's a good reason for the

Re: "return" should not continue script execution, even if used inappropriately

Date:Sun, 6 Jan 2019 16:58:59 -0600 From:Dennis Williamson Message-ID: | You should be able to protect yourself from this by detecting if a script | is not being sourced when it's intended that it must be and acting | accordingly. If you can work out how to

Re: "return" should not continue script execution, even if used inappropriately

Date:Sun, 6 Jan 2019 17:22:36 -0500 From:Chet Ramey Message-ID: | Bash, in its default mode, considers errors from builtins non-fatal. When | you run this in posix mode, which makes a distinction between "special" and | "regular" builtins, it should be a fatal

Re: Maximum length of variable name

Date:Thu, 15 Nov 2018 12:09:46 -0600 From:Eric Blake Message-ID: <8491692f-8d4a-f24f-2744-2de3465a9...@redhat.com> | On 11/15/18 12:00 PM, RAL wrote: | > How is defined the maximum number of characters a variable name can have? | | Bash has no hardcoded

Re: GNU Bash v.4.4.23-5 built-in function 'set' produces variable outputs

Date:Tue, 23 Oct 2018 15:37:15 -0600 From:Bob Proulx Message-ID: <20181023151944393472...@bob.proulx.com> | I'm having a hard time understanding why one would want to turn off | this feature. Because I regard it as a design bug (from ksh, copied into bash) not

Re: GNU Bash v.4.4.23-5 built-in function 'set' produces variable outputs

ps: I did not suggest that $_ should go away, I know that's not going to happen ... just that it would be nice for those who really don't want it to be able to turn it off. kre

Re: GNU Bash v.4.4.23-5 built-in function 'set' produces variable outputs

Date:Mon, 22 Oct 2018 09:37:19 -0400 From:Greg Wooledge Message-ID: <20181022133719.g4wc7uuowwfff...@eeg.ccf.org> | I occasionally run a command like mkdir /tmp/x && cd "$_" cdnd() { mkdir -p "$1" && cd "$1" } Make it as fancy as you want.

Re: GNU Bash v.4.4.23-5 built-in function 'set' produces variable outputs

Date:Fri, 19 Oct 2018 16:21:27 -0400 From:Grisha Levit Message-ID: | I guess it's a bit surprising that $_ is set to just the variable name | and not "the last argument to the previous command", which would be | the full assignment string. Except that a var

Re: Segfault on recursive trap/kill

Date:Sat, 06 Oct 2018 19:53:25 -0400 From:Mike Gerwitz Message-ID: <874ldy1vka@gnu.org> | I haven't inspected the code to see if this is an access | violation or if Bash is intentionally signaling SIGSEGV. I expect that if you did look, you'd probably find

Re: bash sockets: printf \x0a does TCP fragmentation

Date:Sat, 22 Sep 2018 23:51:08 -0600 From:Bob Proulx Message-ID: <20180922231240358868...@bob.proulx.com> | Using the same buffer size | for input and output is usually most efficient. Yes, but as the objective seemed to be to make big packets, that is probably

Re: bash sockets: printf \x0a does TCP fragmentation

Date:Sat, 22 Sep 2018 14:22:19 -0600 From:Bob Proulx Message-ID: <20180922111950901701...@bob.proulx.com> | Primarily a shell script is a command and control program. It is very | good for that purpose. It is typically used for that purpose. That | is the

Re: History of bash's support for self-modifying shell scripts?

Date:Tue, 11 Sep 2018 01:11:41 +0200 From:=?ISO-8859-1?Q?=C1ngel?= Message-ID: <1536621101.1095.13.ca...@16bits.net> | The Thompson shell (up to Sixth Edition UNIX) supported a goto command | that was implemented as an external command(!) that moved the |

Re: Assignment of $* to a var removes spaces on unset IFS.

Date:Mon, 13 Aug 2018 21:36:23 -0400 From:Bize Ma Message-ID: | You both are confused. The original table included You misinterpreted my message. I said two independant things ... first that the bug is already fixed. I didn't say that the fixed version was

Re: Assignment of $* to a var removes spaces on unset IFS.

Date:Mon, 13 Aug 2018 11:51:08 -0400 From:Bize Ma Message-ID: | Bash since 4.3 fails to follow what the documentation describes as that on | an assignment values do not undergo splitting or globing. This is already fixed. What's more, reporting bugs in bash

Re: Unquoted array slice ${a[@]:0} expands to just one word if IFS doesn't have a space

Date:Wed, 1 Aug 2018 09:40:12 -0400 From:Greg Wooledge Message-ID: <20180801134012.r6ojiewtx3npa...@eeg.ccf.org> | https://lists.gnu.org/archive/html/bug-bash/2017-06/msg00283.html A bug in dash which as far as I can tell has since been fixed. |

Re: Unquoted array slice ${a[@]:0} expands to just one word if IFS doesn't have a space

Date:Wed, 1 Aug 2018 09:03:20 -0400 From:Greg Wooledge Message-ID: <20180801130320.wwmnw6ixxztih...@eeg.ccf.org> | "$@" expands to a list of words, and "$*" expands to a single string | with an optional single-character delimiter inserted between substrings. |

Re: Empty ""s in ARG in ${x:+ARG} expand to no words instead of the empty word if prepended/appended with space

Date:Sat, 21 Jul 2018 11:33:18 -0400 From:Chet Ramey Message-ID: <2fe93203-93fd-2a97-ff54-7cb748294...@case.edu> | Even if the whitespace gets stripped out, the quoted null string should | result in an empty argument. Yes, it certainly should (and unless IFS has

Re: Number with sign is read as octal despite a leading 10#

Date:Tue, 10 Jul 2018 18:46:32 -0400 From:Isaac Marcos Message-ID: | set -- 34 034 0034 +34 +034 +0034 -34 -034 -0034 ; | for i do printf '%6s' "$((10#$i))"; shift; done; echo You really ought be only using POSIX defined sh operators, from two

Re: Directing into a variable doesn't work

Date:Sun, 24 Jun 2018 22:26:52 +0700 From:Peter Passchier Message-ID: | I am surprised by the general internal usage of temporary files for | here-documents & here-strings, because (generally speaking) memory is | quite abundant, That's not the real issue -

Re: Bash patches format

pkgsrc (for NetBSD and other systems) has no listed bash maintainer, so ... (and please understand that I in no way speak for pkgsrc or NetBSD here). As long as patch(1) can handle the format, which form (context, unified, ...) patches are released in makes no difference at all. pkgsrc defaults

Re: Conditions with logical operators and nested groups execute "if" and "else"

Date:Wed, 30 May 2018 17:02:58 -0700 From:L A Walsh Message-ID: <5b0f3bb2.1000...@tlinx.org> | I.e. precedence rules seem to work as expected. I am not sure what predence rule you see working as expected, but in sh (bash, or any other Bourne syntax or POSIX shell)

Re: [BUG] 'unset' fails silently under specific conditions

Date:Tue, 1 May 2018 14:36:29 -0400 From:Chet Ramey Message-ID: <71d753dc-036f-7fd7-d703-408c3f8ac...@case.edu> | OK, so which is it? Does an assignment statement preceding a special | builtin in a shell function create a local variable (as

Re: docs incorrectly mention pattern matching works like pathname expansion

Date:Fri, 16 Mar 2018 10:04:07 + (UTC) From:Stormy Message-ID: <1098519022.1750755.1521194647...@mail.yahoo.com> | however, both paths need to be normalized fully before Yes, you're right, I did not consider that, but skipping empty

Re: docs incorrectly mention pattern matching works like pathname expansion

Date:Thu, 15 Mar 2018 22:52:24 + (UTC) From:Stormy Message-ID: <68229887.1497301.1521154344...@mail.yahoo.com> | but there is no way to make it do pathname matching internally. (cd, ls, will surely do it, No, they surely don't - the

Re: Avoiding file-based constraints for tmp files (ws Re: [minor] umask 400 causes here-{doc, string} failure)

Date:Thu, 15 Mar 2018 08:37:39 -0400 From:Greg Wooledge Message-ID: <20180315123739.vd7zdj37irnt4...@eeg.ccf.org> | That said, I think a lot of scripts *do* bend this rule and rely on | the here-document creating a seekable temp file, because

Re: program gets faster when it outputs more on stderr

Date:Sat, 10 Mar 2018 15:46:41 +0100 (CET) From:bash...@jonkmans.nl Message-ID: <20180310144641.62962cc0...@sint.jonkmans.nl> First: | Note that when the fast version is ran with 2>/dev/null, | it also performs slowly. This is not unexpected, and

Re: Unset array doesn't work

Date:Fri, 2 Mar 2018 14:43:02 -0500 From:Chet Ramey Message-ID: <4502a0e5-0600-d294-9af2-4e9eeb0a0...@case.edu> My final comments on this subject: | Perhaps. But bash has never done this. Not from day one. That's 30 years. That a bug (be it a

Re: Unset array doesn't work

Date:Wed, 28 Feb 2018 15:14:58 -0500 From:Chet Ramey Message-ID: | Yes, that's what I said. In the current scope, unset arranges for the | variable to appear unset. In a previous scope, unset

Re: Arm machine does not execute background statement correctly

Date:Wed, 28 Feb 2018 09:03:45 -0500 From:Chet Ramey Message-ID: <46653602-7efa-9e3c-b477-4d22118fd...@case.edu> I didn't see the proginal of this message either, but ... | On 2/28/18 5:31 AM, Lakshman Garlapati wrote: | | > The following

Re: Unset array doesn't work

Date:Wed, 28 Feb 2018 10:27:23 -0500 From:Chet Ramey Message-ID: | These are two different cases -- same context vs. a previous context. Your | example is not the same as the original poster's.

Re: Unset array doesn't work

Date:Tue, 27 Feb 2018 11:18:40 -0500 From:Chet Ramey Message-ID: <21679c48-4064-5683-2d5f-91bfb7668...@case.edu> | It doesn't. Run the following script: OK, that looks good. But now I am very confused. | You'll see that the first expansion

Re: Unset array doesn't work

Date:Tue, 27 Feb 2018 10:18:24 +0800 From:Clark Wang Message-ID:

Re: Unset array doesn't work

Date:Mon, 26 Feb 2018 09:57:10 -0500 From:Clint Hepner Message-ID: | As you say, the intent is to use a particular value of the variable. The fact that unsetting | IFS causes it to use a

Re: Unset array doesn't work

Date:Mon, 12 Feb 2018 09:26:37 -0500 From:Chet Ramey Message-ID: <790ade74-690f-541c-9ab4-635991744...@case.edu> | This is bash's dynamic scoping. The visibility of a local variable is | restricted to a function and its children, and `unset'

Re: $"\t': Bash bug or not?

To put Chet's reply a different way, don't think of $'...' as a dollar expansion ( like ${} $() or $(()) ) it isn't, it is just another form of quoting (very similar to '' quoting) and is processed in the same way, at the same places, as '' quoting would be. In "'xxx'" the single quotes are just

Re: Bug in [ -d ... ] ?

Date:Fri, 3 Nov 2017 08:21:41 -0400 From:Greg Wooledge Message-ID: <20171103122141.tvbmv5sfkcs7h...@eeg.ccf.org> | I am not seeing any evidence of this. As I said, for that particular usage, the effect is the same, either way. The way the

Re: Bug in [ -d ... ] ?

Date:Thu, 2 Nov 2017 16:54:48 + From:Michael F Gordon Message-ID: <20171102165448.ga18...@ee.ed.ac.uk> | Also, replacing := with :- gives "no" on both versions when unquoted | or unquoted. That's because they're doing different

Re: ctrl-w oddity on bash-4.4

I should have also said that's there's no requirement (that I can see anyway) that vi mode in readline be the same as vi. In fact, it obviously cannot be, it is just an editing mode that is somewhat similar to vi. There are going to be things missing (clearly there's no way, and no need, to

Re: ctrl-w oddity on bash-4.4

Date:Thu, 26 Oct 2017 10:04:54 -0400 From:Chet Ramey Message-ID: | Posix doesn't make that distinction. Actually, it does, Input Mode Commands in vi In text input mode, the

Re: Simple sleep scripts causes SEGFAULT

Date:Wed, 25 Oct 2017 21:21:23 -0700 From:Alex Coffin Message-ID:

Re: ctrl-w oddity on bash-4.4

Date:Wed, 25 Oct 2017 10:45:11 -0400 From:Chet Ramey Message-ID: <6751ad10-cccb-0467-a751-c5be8e745...@case.edu> | If you read the discussion in the thread I pointed to last night, `real' | vi supposedly does this kind of thing. I'm not

Re: (OffTopic,) Gnu-Environment restrictions (was Re: Question )

I will send one more reply on this topic - I am replying to this message as I agree with the change of Subject - this is off topic for this list, which is why I will not respond any further to messages about this here. Bob Proulx said (in a message with the original subject):

Re: Bash handling of ENOENT on missing files and directories

Date:Mon, 11 Sep 2017 22:49:47 +0300 From:Jonny Grant Message-ID: | How can an easy update to clarify message "No such file or directory" | introduce a bug? That's easy ... because it is not just

Re: Question

Date:Thu, 14 Sep 2017 20:22:04 -0600 From:Bob Proulx Message-ID: <20170914195843892632...@bob.proulx.com> | However this difference in philosophy does not change the technology | that creating a compiler for an interpreted language is very hard.

Re: /bin/sh should set SHELL to /bin/sh

Date:Thu, 13 Jul 2017 23:02:49 -0400 From:Chet Ramey Message-ID: <102d254a-d321-20c0-b8d6-9f2257861...@case.edu> | Posix, the closest thing we have to a standard description of SHELL, says: It does, but POSIX doesn't say the shell is intended

Re: Unexpected word splitting on $* when IFS is unset

Date:Sat, 24 Jun 2017 07:59:25 -0500 From:Eduardo =?utf-8?Q?A=2E_Bustamante_L=C3=B3pez?= Message-ID: <20170624125925.7vnb4kk35gh3obbk@debian> | I think we can all agree that the rules (and bugs) around | the expansion of $* are too complex.

Re: Unexpected word splitting on $* when IFS is unset

Date:Fri, 23 Jun 2017 11:39:45 -0400 From:Greg Wooledge Message-ID: <20170623153945.ga4...@eeg.ccf.org> | That's what I always thought too, but if commonly used shells like | dash can't even agree on this, then I simply upgrade my response

Re: Unexpected word splitting on $* when IFS is unset

Date:Thu, 22 Jun 2017 07:51:12 -0400 From:Greg Wooledge Message-ID: <20170622115111.gq22...@eeg.ccf.org> | $ dash | $ set -- a b | $ IFS= | $ args $* | 1 args: That is simply broken. Always has been, whatever mistakes were in the

Re: Regression -- can't read input w/stderr redirect

Date:Sun, 18 Jun 2017 14:02:05 -0700 From:L A Walsh Message-ID: <5946ea4d.8030...@tlinx.org> | Side question: Why display that message if there are only | NUL's at the end? I would think it normal for bash to | use and read NUL terminated

<    1   2   3   4   5