Date:Tue, 16 Feb 2021 18:19:48 +0800
From:Koichi Murase
Message-ID:
| For example, this alone doesn't explain why
|
| $ if :; then echo A; fi if :; then echo A; fi
|
| (i.e., the combination "fi if") is a syntax error.
That one is quite a different issue,
Date:Wed, 17 Feb 2021 23:39:07 +0800
From:Koichi Murase
Message-ID:
Andreas answered the technical part of your message, and I agree
with that.
| Anyway, even if the POSIX specifies some inconsistent grammar, I feel
| that cannot be the reason that Bash behaves
Date:Thu, 18 Feb 2021 01:34:59 +0800
From:Koichi Murase
Message-ID:
| ever written a shell parser?
From scratch, no, but I maintain one.
With all the details
It isn't all that hard, but isn't trivial
either, and amounts to quite a bit of code
(and parsing a
Date:Tue, 16 Mar 2021 09:31:24 -0400
From:Chet Ramey
Message-ID: <31aff163-9e61-d34a-be79-40c7e09a8...@case.edu>
| If you want to set PWD instead of letting cd/pushd/popd manage it,
| all bets are off.
I agree with that as far as what you get when you expand $PWD
Date:Tue, 16 Mar 2021 13:26:30 +0100
From:Alex fxmbsw7 Ratchev
Message-ID:
| no idea about your internal rules of keyword and builtin but clearly its
| gotta parse it at most 1. level otherwise its big security fault isnt it
No, it isn't. No more than
Date:Tue, 16 Mar 2021 18:01:24 -0400
From:Jay via Bug reports for the GNU Bourne Again SHell
Message-ID: <86f1f224-2930-ee73-5431-6e130d92f...@aim.com>
First, thanks Lawrence for the translation from RTF, I am one of
the people he intended to help... The RTF form I
Date:Tue, 16 Mar 2021 22:08:17 -0500
From:Dennis Williamson
Message-ID:
| In any case this points to larger chunks being more efficient.
This is not news, doing reads (or writes) using bigger buffers (more
bytes at a time) means less system calls, and compared to
Date:Wed, 17 Mar 2021 08:28:26 +0100
From:Alex fxmbsw7 Ratchev
Message-ID:
| you write like when word splitting no use double quotes
| sure but as far as i understood:
| key='$( faulty_command )'
| unset -v assoc["$key"]
| would still get expanded
associa
Date:Wed, 17 Mar 2021 09:12:19 -0400
From:Chet Ramey
Message-ID:
| If you don't modify PWD, PWD always reflects the current working directory,
Of course, but how is that relevant?
But even that isn't actually specified, if one does a popd does PWD
not change? T
Date:Fri, 19 Mar 2021 09:12:34 +0100
From:Alex fxmbsw7 Ratchev
Message-ID:
| eval $'alias n=bla\nn() { type $FUNCNAME ; }\nn'
| bla is a function
| bla ()
| {
| type $FUNCNAME
| }
|
| it was supposed to be n() ..
nothing to do with the \n that
Date:Fri, 19 Mar 2021 16:23:55 +0700
From:Robert Elz
Message-ID: <18800.1616145...@jinx.noi.kre.to>
Sorry for all the typos...
| nothing to do with the \n that woukd have
| worked just fine.
I was "typing" that reply from my phone, something I
Date:Fri, 19 Mar 2021 17:59:18 +0300
From:=?UTF-8?B?T8SfdXo=?=
Message-ID:
| Not much related, but isn't this supposed to work?
It is perhaps no surprise (considering their relationship with dash)
that the FreeBSD and NetBSD shells (at least a reasonably up to d
Date:Sun, 21 Mar 2021 22:42:19 -0400
From:Greg Wooledge
Message-ID:
| One or more of your assumptions are wrong.
|
| Bash uses "dynamic scope" when it expands variables.
Note that some other shells don't really have local variables at all, there
are only glob
Date:Tue, 23 Mar 2021 08:43:54 +0200
From:=?UTF-8?B?T8SfdXo=?=
Message-ID:
| $ a=b >&2 u
| No command u found, did you mean:
Kind of interesting that ksh93 seems to do the same thing. No other
shell I was able to test however (including ancient pdksh
Date:Tue, 23 Mar 2021 13:10:19 +0300
From:=?UTF-8?B?T8SfdXo=?=
Message-ID:
| $ echo a > a
| $ echo b > b
| $ alias l='< ' a=b
| $ l a cat
| a
|
| I can't think of any reason not to expand `a' there.
I can think of a reason (though the NetBSD sh does
Date:Tue, 23 Mar 2021 14:51:02 +0300
From:=?UTF-8?B?T8SfdXo=?=
Message-ID:
| (except aliases that
| appear in a place where only a here document body may appear, but no shell
| does that the way I think they'd do, so..)
What do you expect there? A here doc b
Date:Tue, 23 Mar 2021 20:27:27 +0200
From:=?UTF-8?B?T8SfdXo=?=
Message-ID:
| Apparently I couldn't make myself clear there,
Perhaps, or I was just failing to understand. Never mind.
But this (as you know) was nothing like I imagined you meant.
| # doesn't wo
Date:Wed, 24 Mar 2021 11:15:11 +0300
From:=?UTF-8?B?T8SfdXo=?=
Message-ID:
| I think I got the general idea of aliases now
I'm not sure why you want or need that, aliases
are dumb (bizarre) and shoukd be deleted...
I keep trying to get tge POSIX people to
remove
Date:Thu, 25 Mar 2021 08:00:20 +0200
From:=?UTF-8?B?T8SfdXo=?=
Message-ID:
| They are fine as an interactive feature but definitely don't belong in
| shell scripts.
They're not fine anywhere, anything sane that can be done with an alias
can be done better with
Date:Sun, 28 Mar 2021 22:01:14 +0300
From:=?UTF-8?B?T8SfdXo=?=
Message-ID:
| No. An "explicit" empty string would be '', "", or something like that.
No, not in sh it isn't - all quotes do is hide the effects of special
characters (and prevent some uses, eg: as a
Date:Mon, 29 Mar 2021 17:31:23 +0200
From:Valentin Lab
Message-ID: <604a4dab-afc5-cd5e-ee80-64d3dfb2e...@kalysto.org>
| In 4.3, this makes sense to me. EXIT trap is not available and not executed.
|
| In >4.3, I don't understand: 'trap -p' is displaying a trap
Date:Tue, 30 Mar 2021 07:33:08 +0300
From:=?UTF-8?B?T8SfdXo=?=
Message-ID:
| The same goes for the job table right?
Yes, though there's no posix explanation for that (no expectation
there that code would ever want to examine it).
| None of ash derivatives (inc
Date:Thu, 1 Apr 2021 11:36:14 -0400
From:Greg Wooledge
Message-ID:
| On Thu, Apr 01, 2021 at 01:36:59AM -0700, greyw...@starwolf.com wrote:
| > The following is valid shell code:
| >
| > d=($(ls /usr/src/pkg/*/$1));
|
| Syntactically valid, but seman
Date:Thu, 1 Apr 2021 13:18:07 -0400
From:Greg Wooledge
Message-ID:
| 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
Date:Thu, 1 Apr 2021 14:40:13 -0700
From:Greywolf
Message-ID: <354ec4df-c24e-d82a-32ad-788a352a5...@starwolf.com>
| Or do you mean my coding style
It was that,
| (which has been valid for over 25 years)?
| (why's everyone bagging on my style and ignoring my or
Date:Thu, 01 Apr 2021 21:33:31 -0400
From:wor...@alum.mit.edu (Dale R. Worley)
Message-ID: <874kgpqxlg@hobgoblin.ariadne.com>
| I was going to ask why "else {" works,
Wrong question. That one is easy. What follows
'else' is a list and the simplest form of a li
Date:Fri, 2 Apr 2021 23:06:40 +0800
From:konsolebox
Message-ID:
| > The right question would be why '} else' works.
|
| This inconsistency should be fixed and prevent people from
| using it wrong. `}; else` should work
Yes.
| but not `} else`
No, that
Date:Fri, 02 Apr 2021 09:02:40 +0200
From:Andreas Schwab
Message-ID: <87o8exp3sf@linux-m68k.org>
| The two case are not really different, they are covered by the same
| rule:
Yes, I knew that ... but they are different, as in the "else {" case
the '{' is in t
Date:Sun, 04 Apr 2021 20:27:15 -0400
From:wor...@alum.mit.edu (Dale R. Worley)
Message-ID: <87wntha84c@hobgoblin.ariadne.com>
| The manual page says
|
|if list; then list; [ elif list; then list; ] ... [ else list; ] fi
|
| so clearly there shoul
Date:Tue, 6 Apr 2021 22:39:55 +0800
From:konsolebox
Message-ID:
| @ means everything or nothing. Unbound variable errors should not apply to
it.
I know nothing about namerefs and arrays and stuff like that,
but did you consider the possibility that after
Date:Wed, 07 Apr 2021 22:24:27 -0400
From:wor...@alum.mit.edu (Dale R. Worley)
Message-ID: <87a6q9ikdg@hobgoblin.ariadne.com>
| "The documentation is the contract between the user and
| the implementer." If something undocumented happens to work, there is
|
Date:Tue, 27 Apr 2021 05:57:40 +
From:"Beer, Mathis"
Message-ID: <3024777.xmhlYjkYgV@ka-nl-mbeer>
| Given a background process that has exited before the script got to wait -n:
|
| function foo() { return 1; }
| foo & FOO_PID=$!
|
| function bar() { sl
Date:Fri, 30 Apr 2021 12:28:32 +0530
From:Inian Vasanth
Message-ID:
| Why is it the case? Shouldn't the glob expression just serve the !(8)
| pattern to exclude and simply do a no-op for the extra * character?
The '*' means "sero or more of the preceding", the
Date:Fri, 30 Apr 2021 14:53:58 +0800
From:konsolebox
Message-ID:
| {{ }} - Similar to { }, but runs like a function so variables can be
| declared local
>From below, I suspect you mean more, though you haven't fully defined what you
mean, but extending local to
Date:Fri, 30 Apr 2021 19:28:47 +0800
From:konsolebox
Message-ID:
| That was my initial idea too, but I think it's better to just leave {
| } alone as modifying its behavior still has a chance of breaking
| scripts.
It does have, though most usage of local is
Date:Tue, 4 May 2021 09:28:04 -0400
From:Chet Ramey
Message-ID:
| The issue with the BSDs and terminal devices is that the current code
| only checks for -1/ESPIPE, but they return a different value for errno
| (EINVAL? I forget.)
On traditional unix, since fo
Date:Thu, 13 May 2021 23:52:20 +0200
From:Alex fxmbsw7 Ratchev
Message-ID:
|
https://www.ibm.com/support/pages/exit-code-127-means-jobs-command-can-not-be-found-or-executed
I have no idea what info that reply was
intended to add, but it us not useful.
| On Th
Date:Mon, 17 May 2021 21:35:49 +0200
From:Alex fxmbsw7 Ratchev
Message-ID:
| return code 127 by not found cmd or job
| .. ?
Yes, we always knew that, that was never interesting. The question
was why it was happening when the job still existed.
Chet has supp
Date:Thu, 24 Jun 2021 21:03:22 -0400
From:Greg Wooledge
Message-ID:
| Bash is ALL about these special cases. If you don't like it, don't write
| code that uses it. In any sensible programming language, var="$@"
| would have been an error. In bash, it's not.
Date:Fri, 25 Jun 2021 12:11:33 -0400
From:Greg Wooledge
Message-ID:
| That matches the behavior that I saw (and pasted on this mailing list the
| other day). (Which by the way is *not* the same as "$*" unless IFS happens
| to be unset or to begin with a space.
Date:Tue, 10 Aug 2021 10:22:29 -0400
From:Chet Ramey
Message-ID: <731876fc-39c0-4388-0c9e-bf560921b...@case.edu>
| In this case, you are using features outside what POSIX specifies.
Using a variable name that's outside what POSIX specifies is hardly
using a feature
Date:Wed, 11 Aug 2021 10:16:42 -0400
From:Chet Ramey
Message-ID: <26e01365-d7f0-448d-dc4d-83f244bd0...@case.edu>
| As long as POSIX doesn't define a variable to have some special meaning, it
| doesn't have anything to say about how a shell chooses to use it. It's
Date:Wed, 11 Aug 2021 15:31:08 -0400
From:Chet Ramey
Message-ID: <87b7cb49-444f-aa06-198d-57f4071a0...@case.edu>
| I believe I'd rather have variables behave as they're documented. It's more
| predictable.
I'm not sure I follow the logic that leads to that conclu
Date:Mon, 16 Aug 2021 22:16:29 -0400
From:"Dale R. Worley"
Message-ID: <878s10yfwi@hobgoblin.ariadne.com>
| 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
Date:Mon, 16 Aug 2021 22:35:12 -0400
From:"Dale R. Worley"
Message-ID: <875yw4yf1b@hobgoblin.ariadne.com>
| Back in the old, old days, there was a program named "glob" that did
| pathname expansions.
That's correct.
But:
| So you wouldn't say
|
|c
Date:Sat, 21 Aug 2021 07:28:23 +0200
From:Emanuele Torre
Message-ID:
| I have also read that gettimeofday() is considered obsolete and is
| deprecated by POSIX.
It is being removed as a required interface, but it still exists
everywhere (and will for a very lon
Date:Fri, 27 Aug 2021 15:05:52 +
From:nigelberlinguer via Bug reports for the GNU Bourne Again SHell
Message-ID:
<0IgsinjPxg5VSubCxyc64u9axdDTEubUNcQFmIaPyduotl2CyQ9g71uoLtpmXL2hUph1_eHzVRnEZ7vyyHFKqqy3OlPydQXccd2CkHyzpjA=@protonmail.com>
| I am trying to use
Date:Fri, 27 Aug 2021 17:20:39 +
From:nigelberlinguer
Message-ID:
| It should be noted though, that the POSIX requirement by "Guideline 7"
| is not guided by actual portability in the technical sense but by a
| rule written in the POSIX standard.
Those gu
Date:Sat, 28 Aug 2021 15:26:28 +
From:hancooper
Message-ID:
| Would the code break if I use shortopts="Vuhv:s" (allows getopts
| to issue errors, not in silent mode) but also have the (":") and
| ("?") checks inside the case statement?
Not break, but the
Date:Fri, 1 Oct 2021 09:59:44 -0400
From:Chet Ramey
Message-ID:
| Yes. When the shell runs `exec', it assumes the execed program will overlay
| the shell process. To make that happen transparently, it has to undo things
| it has done: it ends job control and re
Date:Sun, 10 Oct 2021 21:09:53 -0400
From:Eli Schwartz
Message-ID: <4a362385-066d-0795-9a02-ff8bbb920...@archlinux.org>
| So I wonder, if bash already in this exact case attempts to open() the
| file and read() it to look for a shebang, what's the harm in assuming
Date:Mon, 11 Oct 2021 10:26:12 +0200
From:Alex fxmbsw7 Ratchev
Message-ID:
| i still have hopes it syncs, arent pipes file fifos or something
it makes no difference, you cannot sync something
which has not yet been written, and in the
examples it us very likely
Date:Mon, 11 Oct 2021 11:00:54 -0400
From:Chet Ramey
Message-ID: <45ecd950-9e9b-553b-132b-04d1dcfad...@case.edu>
| When execve returns this error for what is a clearly invalid reason,
The problem is that sometimes it will probably be an invalid reason
(that's where
Date:Fri, 29 Oct 2021 11:59:02 -0700
From:L A Walsh
Message-ID: <617c4476.2010...@tlinx.org>
| Bash is a command_line console language designed to execute commands
| locally in the context of the user. Local user access to a console,
| from a security standpo
What POSIX says about this (which you probably know already) is:
A loop shall enclose a break or continue command if the loop
lexically encloses the command. A loop lexically encloses a
break or continue command if the command is:
[and just paraphrasing the conditions]
I agree, this looks to be broken in bash - "command -p cmd" is (logically)
oldpath=$PATH
PATH=/standard:/system:/path
cmd
PATH=$oldpath
and should act (as if) that way.
What's more, from all the shells I have tested, bash is the only one
to behave like this, every
Date:Mon, 1 Nov 2021 12:03:48 -0400
From:Greg Wooledge
Message-ID:
| > bash: : command not found
| > bash: : command not found
|
| Because this is you, I can't be sure whether you are correctly pasting
| the output from your terminal into email,
Actually,
Date:Mon, 1 Nov 2021 16:31:51 -0400
From:Greg Wooledge
Message-ID:
| unicorn:~$ alias cat=' '
no I meant
alias cat="' '"
though which quote in inside doesn't matter,
and using \ quoting is possible too
nx$ alias xx='\ '
jinx$ xx
-bash: : command not
Date:Wed, 3 Nov 2021 10:35:09 -0400
From:Chet Ramey
Message-ID: <3f617355-cbd2-1e62-358e-dbf9487ce...@case.edu>
| The OP assumes that the value of this functionality is self-evident. I'm
| a little more skeptical. How does it help make things easier for users?
I
Date:Wed, 17 Nov 2021 12:35:42 +
From:=?utf-8?Q?Jo=C3=A3o_Almeida_Santos?=
Message-ID:
| While testing the heredoc mode, I realized that the $ is not
| interpreted as variable expansion.
It depends how you set up the heredoc, please give an example of
what
Date:Wed, 17 Nov 2021 18:45:05 +
From:=?utf-8?Q?Jo=C3=A3o_Almeida_Santos?=
Message-ID:
| No, it's on the email...
It wasn't, but some lists filter attachments (remove them) - this might be one.
| bash-5.1$ echo $PATH
|
/usr/bin:/bin:/usr/sbin:/sbin:/us
Date:Wed, 17 Nov 2021 15:47:37 -0500
From:Chet Ramey
Message-ID: <420281e7-f3c4-8054-d390-9378080c2...@case.edu>
| Every modern shell uses `$PATH' as the here-document delimiter
Depends what you call modern shells - some ash derived shells (at least)
don't, because
Date:Thu, 18 Nov 2021 10:34:40 +0100
From:Harald Dunkel
Message-ID:
| at least due to unbalanced parenthesis?
Greg's reply was correct, but he didn't explicitly address that point.
In sh, characters like { } [ ] (but not ( and )) are just characters.
In some scena
Date:Thu, 18 Nov 2021 15:46:10 -0500
From:Chet Ramey
Message-ID: <5c36d290-0e6e-2aa0-f388-20ec9369a...@case.edu>
| Yeah, that's a bug. But it's probably baked in.
Very. Just stopping parsing expansions while reading the here doc
delim string would be easy (well, p
Date:Fri, 19 Nov 2021 13:40:16 -0600
From:Eric Blake
Message-ID: <2029194016.5xn6gydfbtwmv...@redhat.com>
| According to POSIX, perl should REALLY be passing a "--" argument
| between "-c" and the scalar string given by the user; see
| https://www.austingrou
Date:Sat, 20 Nov 2021 11:33:37 -0500
From:Chet Ramey
Message-ID: <4addb789-50b6-12a5-7b8a-8a082abaa...@case.edu>
| I'm skeptical, but willing to be convinced. Bourne's shell allowed EOF to
| terminate all sorts of things (quoted strings, command substitutions, her
Date:Sat, 20 Nov 2021 15:19:33 -0500
From:Chet Ramey
Message-ID:
| Right. Purposeful.
There's a difference between done intentionally for pragmatic reasons,
and done intentionally because it is the right thing to do and people
should depend upon it remaining that
Date:Tue, 23 Nov 2021 11:09:51 -0500
From:Chet Ramey
Message-ID: <3a5f6f3a-aa73-d8ac-46f4-46467d5b3...@case.edu>
| > I'll run our tests against the newest (released) bash
|
| OK. However, since, as I said, the devel branch has a completely different
| implemen
Date:Sat, 27 Nov 2021 13:57:57 -0500
From:Chet Ramey
Message-ID: <5217c48e-c989-a163-5673-38995e35a...@case.edu>
Warning: long message follows, give yourself time to digest it.
| OK, if you do end up building the devel branch, I'd be interested
| in these results
Date:Sun, 28 Nov 2021 20:51:33 +0100
From:Alex fxmbsw7 Ratchev
Message-ID:
| a small comment on that /bin in PATH code.. is invalid, you need to match
| first non : beginning ahe not : ending end
| case :$PATH: would fix it
If it was the slightest bit relevan
Date:Wed, 8 Dec 2021 09:56:50 -0500
From:Chet Ramey
Message-ID:
Let's take this in smaller steps, and try and sort out one issue
at at time.
First, I think you're under a mistaken impression, which is
revealed in the following paragraph.
| The real question is wh
Date:Tue, 18 Jan 2022 12:44:46 +0100
From:l.bash...@scarydevilmonastery.net
Message-ID:
<1642506286.659529.80113.nullmai...@latitude.scarydevilmonastery.net>
|a: defining an empty function will throw a syntax error
|b: defining an empty bodies flow control
Date:Mon, 24 Jan 2022 12:03:39 -0500
From:Chet Ramey
Message-ID: <3aeb9d02-b134-216f-6d11-921e42941...@case.edu>
| Except it's not unconditional. You have to accommodate ${x#$'value'} in
| the here-document expansion path because "${x#$'value'}" is processed for
Date:Mon, 24 Jan 2022 19:53:03 +0100
From:Andreas Kusalananda =?utf-8?B?S8OkaMOkcmk=?=
Message-ID:
| Why would people want it to do that (i.e. export PS1)?
It isn't exporting PS1 that's the issue, it is importing it. And that
I rely on quite frequently. (Of c
Date:Tue, 25 Jan 2022 05:45:23 +0800
From:konsolebox
Message-ID:
| As for me whatever it is, it should be done consistently and with no
| compromise.
I have no idea why you decided to send this message to me (as well as the
list), my message was entirely about
Date:Mon, 24 Jan 2022 23:00:38 +
From:konsolebox
Message-ID:
| It's meant to be a general reply to the thread.
It was just that you replied to Andreas' message (the reply to my message)
but didn't include him in the list of recipients, just me & the list.
Date:Tue, 1 Feb 2022 10:23:53 -0500
From:Chet Ramey
Message-ID: <1e33f111-b9ff-2d70-adf8-934906321...@case.edu>
| Historically, bash (and ksh93) has favored the former. Just about all the
| other shells claiming some sort of POSIX conformance favor the latter (all
Date:Tue, 1 Feb 2022 15:39:06 -0500
From:Chet Ramey
Message-ID: <2816cf78-d7be-b9e1-733d-12427b04c...@case.edu>
| When you say "just parsed," when are aliases expanded?
During lexical analysis, right between when the input is read (if it
is read, and isn't from som
Date:Wed, 02 Feb 2022 05:25:30 -0800
From:L A Walsh
Message-ID: <61fa864a.7090...@tlinx.org>
| On 2022/01/31 20:40, Martijn Dekker wrote:
| > On the latest code from the devel branch:
| I can't say for sure, but it would be interesting if anyone else
| has th
And I forgot to say, that obviously for this, aliases need to be
being expanded, if they're not, there cannot possibly be an issue
with aliases, can there?
kre
Date:Wed, 2 Feb 2022 11:38:30 -0500
From:Chet Ramey
Message-ID: <7c422cbb-bba8-0a57-a565-eeb115120...@case.edu>
| > How accurately can you reconstitute? That is, can you maintain the
| > difference between $(a b) and $( a b ) for example ? How about $(a b) ?
Date:Wed, 02 Feb 2022 17:18:08 -0800
From:L A Walsh
Message-ID: <61fb2d50.7010...@tlinx.org>
| My posix non-conformance issue has to do with bash not starting with
| aliases enabled by default in all default invocations.
If you're using aliases in scripts, then j
Date:Thu, 03 Feb 2022 09:05:53 -0800
From:L A Walsh
Message-ID: <61fc0b71.2080...@tlinx.org>
| There is no way you can tell me that:
| declare var='v'
| declare -i ivar=1
|
| are more clear than:
|
| my var='v'
| int ivar=1
I can, easily -- for the fo
Date:Thu, 3 Feb 2022 13:31:52 -0500
From:Chet Ramey
Message-ID: <46753625-7fcc-8296-c31e-7a5d1fc38...@case.edu>
| My argument is like yours -- is there a return on the investment of effort
| to make it worth doing, if the current state preserves semantics?
Sure,
Date:Thu, 3 Feb 2022 16:19:08 -0500
From:Greg Wooledge
Message-ID:
| This declares the variables at the wrong scope.
You are correct - I never normally use "declare" for anything, so
I had forgotten that it was essentially a clone of "local" (rather
than "local" b
Date:Fri, 4 Feb 2022 21:06:11 +0100
From:Alex fxmbsw7 Ratchev
Message-ID:
| now changing this to dynamic eof marker
There is no such thing. Unlikely (*VERY* unlikely) there ever will be.
| cat <<$( printf leet )
| $( printf leet )
| $( printf leet )
Date:Sun, 6 Feb 2022 18:01:03 -0500
From:Greg Wooledge
Message-ID:
| I urge you to learn one of these other languages, and use it.
|
| Bash is a shell, not a full general-purpose programming language. It's
| not suited to all tasks. Many other languages are
Date:Sun, 13 Feb 2022 21:38:19 -0500
From:"Dale R. Worley"
Message-ID: <87o83a895w@hobgoblin.ariadne.com>
| The two a-priori plausable behaviors are for the backslash to be taken
| literally (which is what happens) or for it to vanish as some sort of
| incom
Date:Sun, 13 Feb 2022 22:38:47 -0600
From:Dennis Williamson
Message-ID:
| It occurs to me that the -r option of read is related.
It is - if a backslash is the final char of input (ie: no newline follows)
when read is used without -r, what happens to that \ will
Date:Wed, 16 Feb 2022 16:10:40 +0800
From:Daniel Qian
Message-ID:
| I encountered a problem that long variable valur get corrupteds
| sometimes.
That looks like the bug tgat is fixed by patch 14 to bash 5.1
Your bash is only at patch 8. Get all the released pa
Date:Wed, 23 Mar 2022 07:38:39 -0400
From:Greg Wooledge
Message-ID:
| But as it happens, the writers of the POSIX standards *did* use that
| word in some places, and so we have to live with it.
The usage much predates POSIX or any of the previous standards.
It i
Date:Wed, 23 Mar 2022 01:48:48 -0700
From:L A Walsh
Message-ID: <623adef0.1060...@tlinx.org>
| POSIX phraseology applies to the POSIX language.
Which bash is an (extended) implementation of.
| In 'C'
Completely irrelevant.
| In perl:
Also irrelevant.
I cannot imagine what you believe any of that has to do
with bash. It is clearly entirely related to ssh/sshd
and the way you are using it.
I suspect the "problem" relates to a misunderstanding
of what the -i ootion to ssh actually does, but you
should talk to ssh people, not bash people, to conf
Not a bug.
Do not use && || as if they were a replacement for if then else fi
they aren't. In some simple cases it all works out OK, but not in
general, as you discovered. If you mean if x; then y; else z; fi
then write that, not x && y || z
The way and-or lists work, is that the first command
Date:Fri, 13 May 2022 22:36:56 -0400
From:"Dale R. Worley"
Message-ID: <87ilq8hmbb@hobgoblin.ariadne.com>
| Reading your message, I believe that the rule can be stated as follows,
| and I'd thank you to check it:
OK
| && and || have the same precedence, an
Date:Fri, 13 May 2022 23:27:50 -0400
From:Greg Wooledge
Message-ID:
| Not really.
What's the difference?
| Let's say you have a bunch of commands strung together like this:
|
| a && b || c && d || e && f || g
|
| We start with the shell's command parser
Date:Wed, 15 Jun 2022 07:37:07 -0400
From:Greg Wooledge
Message-ID:
| Bash does not ship a man page named "wait". What are you actually
| reading?
I assumed the section of "man bash" which describes the wait
builtin command, describes the various exit status po
Date:Wed, 15 Jun 2022 12:14:22 -0700
From:AA
Message-ID: <023de9fa-06b2-95f1-bf49-7d8a416a8...@memeplex.com>
| Therefore, if you
| could educate/direct me to the right place to ensure the patch at the
| link above is considered, I'd be happy to follow up.
I d
Date:Wed, 6 Jul 2022 01:34:53 +0300
From:Yair Lenga
Message-ID: <6b7e3c85-5fcd-459e-a41c-e2803b0e7...@gmail.com>
| Function main () {
| Local x. # x is local
| For x in a b ; do process $x ; done
| }
|
| Vs.
| # x is global, all function will
Date:Fri, 8 Jul 2022 12:08:38 -0400
From:Chet Ramey
Message-ID:
| This is where folks like kre are going to argue.
Am I? I was keeping out of this one!
As long as valid expressions are parsed correctly, I don't think it
really matters all that much what you do
1 - 100 of 531 matches
Mail list logo
