On 3/17/21 4:04 PM, Greg Wooledge wrote:
On Wed, Mar 17, 2021 at 09:58:24PM +0200, Ilkka Virta wrote:
On Wed, Mar 17, 2021 at 8:26 PM Greg Wooledge wrote:
I thought, for a moment, that bash already used $'...' quoting for
newlines, but it turns out that's false. At least for declare -p.
It w
Le 17/03/2021 à 21:13, Alex fxmbsw7 Ratchev écrivait :
hm at least now we know array declare -p formatting would work in
workarounds, good to .. :)
Instead of:
var=$'1\e[G\e[K2' ; declare -p var
do:
var=$'1\e[G\e[K2' ; printf 'declare -- %s\n' "${var@A}"
And if you want a human readable dum
Le 17/03/2021 à 20:58, Ilkka Virta écrivait :
On Wed, Mar 17, 2021 at 8:26 PM Greg Wooledge wrote:
I thought, for a moment, that bash already used $'...' quoting for
newlines, but it turns out that's false. At least for declare -p.
It would be nice if it did, though. Newlines, carriage retur
hm at least now we know array declare -p formatting would work in
workarounds, good to .. :)
On Wed, Mar 17, 2021 at 9:05 PM Greg Wooledge wrote:
> On Wed, Mar 17, 2021 at 09:58:24PM +0200, Ilkka Virta wrote:
> > On Wed, Mar 17, 2021 at 8:26 PM Greg Wooledge wrote:
> >
> > > I thought, for a mo
On Wed, Mar 17, 2021 at 09:58:24PM +0200, Ilkka Virta wrote:
> On Wed, Mar 17, 2021 at 8:26 PM Greg Wooledge wrote:
>
> > I thought, for a moment, that bash already used $'...' quoting for
> > newlines, but it turns out that's false. At least for declare -p.
> > It would be nice if it did, thoug
On Wed, Mar 17, 2021 at 8:26 PM Greg Wooledge wrote:
> I thought, for a moment, that bash already used $'...' quoting for
> newlines, but it turns out that's false. At least for declare -p.
> It would be nice if it did, though. Newlines, carriage returns, escape
> characters, etc.
>
It does in
On Wed, Mar 17, 2021 at 01:55:56PM -0400, Eli Schwartz wrote:
> On 3/17/21 12:43 PM, Alex fxmbsw7 Ratchev wrote:
> > it makes the output no more possible if interpreted by tty
> > the \e's get processed by terminal and no more .. just an example where it
> > is so:
> >
> > var=$'1\e[G\e[K2' ; decl
On 3/17/21 12:43 PM, Alex fxmbsw7 Ratchev wrote:
> it makes the output no more possible if interpreted by tty
> the \e's get processed by terminal and no more .. just an example where it
> is so:
>
> var=$'1\e[G\e[K2' ; declare -p var
>
> if G was H for other line then it completly messes the ter
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
On 3/16/21 11:20 PM, Robert Elz wrote:
| 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 (even the
pwd command, so using `pwd` as an alternative if PWD has been manually
set is not necessa
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
okay, cool, thank you for valuable infos =))
On Tue, Mar 16, 2021 at 2:31 PM Chet Ramey wrote:
> On 3/16/21 6:23 AM, Alex fxmbsw7 Ratchev wrote:
> > .. ?
> >
> > # root ~/ogt2/confs ( 0 @ 2 ) boost ( 42098 @ 1615890149.004363 ==
> > 2021-03-16+11:22:2920 ) #
> > PWD=/bla
>
> No. If you want to s
On 3/16/21 6:23 AM, Alex fxmbsw7 Ratchev wrote:
.. ?
# root ~/ogt2/confs ( 0 @ 2 ) boost ( 42098 @ 1615890149.004363 ==
2021-03-16+11:22:2920 ) #
PWD=/bla
No. If you want to set PWD instead of letting cd/pushd/popd manage it,
all bets are off.
Just like setting HOME changes tilde expansion.
but is it a bug
its a bug to use heavy subshells for such
i understand the addment of this case tho
On Tue, Mar 16, 2021 at 1:23 PM Chris Elvidge wrote:
> On 16/03/2021 10:23 am, Alex fxmbsw7 Ratchev wrote:
> > .. ?
> >
> > # root ~/ogt2/confs ( 0 @ 2 ) boost ( 42098 @ 1615890149.004363 ==
> > 2
On 16/03/2021 10:23 am, Alex fxmbsw7 Ratchev wrote:
.. ?
# root ~/ogt2/confs ( 0 @ 2 ) boost ( 42098 @ 1615890149.004363 ==
2021-03-16+11:22:2920 ) #
PWD=/bla
# root /bla ( 0 @ 2 ) boost ( 42148 @ 1615890199.128728 ==
2021-03-16+11:23:1920 ) #
Yes, it seems \w (and \W) take their values from
that ive written not nothing.. big thanks for your true efford, and thanks
for future bugfixing it, ..important issue
i also had the same with && after [[ somewhere with also fail
but since i switched to one command one line it all yet works, the bit that
im trying
thanks, peace
On Tue, Nov 17, 2
On 11/17/20 7:56 AM, Greg Wooledge wrote:
On Mon, Nov 16, 2020 at 10:36:48PM -0800, L A Walsh wrote:
or (to reproduce error):
an_alias='res=() t=""
for ci in "${!foo[@]}"; do \
Nice detective work there. I can confirm this in Debian's bash 5.0.3:
unicorn:~$ alias foo='a=() b=""
$ alias x='a=()
foo
echo $a'
$ x
foo
$ declare -p a
declare -a a=([0]="foo")
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for something completely different."
On Mon, Nov 16, 2020 at 10:36:48PM -0800, L A Walsh wrote:
> or (to reproduce error):
> an_alias='res=() t=""
>for ci in "${!foo[@]}"; do \
Nice detective work there. I can confirm this in Debian's bash 5.0.3:
unicorn:~$ alias foo='a=() b=""
> for i in 1; do echo hi; done'
unicorn:~
On 2020/11/16 11:02, Alex fxmbsw7 Ratchev wrote:
on my way for a new paste
Anytime you start going over multiple lines in an alias, you
need to consider the use of a function, where 'need' would ideally
increase in proportion to the number of lines you are including.
For increased readability,
On Mon, Nov 16, 2020 at 9:38 PM Robert Elz wrote:
>
> Personally I'd go further and suggest that no-one should ever use aliases
> for anything, ever ...
>
I don't understand why people "hate" aliases so much. :) For me it's much
simpler/shorter than functions. And the "alias" command (without an
on my way for a new paste, i came over more such unexpected ';' token
errors, yet i seemed for workaround\compatibility to work around em by not
using ; at all, also on end of final done cause that error would appear
im still working on making my code acceptable
On Sat, Nov 14, 2020, 20:29 Alex f
Date:Mon, 16 Nov 2020 08:49:21 -0500
From:Greg Wooledge
Message-ID: <20201116134921.gn...@eeg.ccf.org>
| If a bug can actually be pinpointed and demonstrated,
| I'm sure Chet would care.
Chet might. I don't. I doubt many others do.
| It's too convoluted. Ju
On Mon, Nov 16, 2020 at 08:37:05PM +0700, Robert Elz wrote:
> Dale's point, with which I agree, is that you shouldn't even be attempting
> using aliases for things like that. If there is some bug there, I don't
> care, and I doubt anyone else does either.
If a bug can actually be pinpointed and d
Date:Mon, 16 Nov 2020 13:52:55 +0100
From:Alex fxmbsw7 Ratchev
Message-ID:
| small conclusion: . code works, eval "$( < file )" worked, but alias
| version not without empty newline
Dale's point, with which I agree, is that you shouldn't even be attempting
usin
thank you sir dale, while i was cleaning up the code for another paste with
more details i came across that when i add a empty newline before the first
for, the bug line disappears
small conclusion: . code works, eval "$( < file )" worked, but alias
version not without empty newline
..
im sorry i
Alex fxmbsw7 Ratchev writes:
> i code shortened coding codings, or at least wish to
> here in my x7yz control script i '. -- +al' a ./+al file which then
> [...]
> any ideas ?
This is *really* hard to understand. None of the names of files,
variables, or functions describes what they are intende
On Sunday 5 October 2008 17:17, Antonio Macchi wrote:
> #!/bin/bash -e
>
> trap "rm test_fifo" 0
> mkfifo test_fifo
>
> ls / > test_fifo &
>
> exec 9<&0
>
> while read dirname
> do
>echo $dirname
>
># if I wait, exits!!!
>read -t 2 -p "press enter..." 0<&9
> done < test_fifo
>
>
28 matches
Mail list logo
