Re: about the local not-on-every-function-separately var issue
im sorry to not be able to reply to all your stuffs
you didnt make it easy
im happy it works for me now
On Mon, Mar 22, 2021 at 3:43 AM Greg Wooledge wrote:
>
> On Mon, Mar 22, 2021 at 03:12:25AM +0100, Alex fxmbsw7 Ratchev wrote:
> > i realize its somewhat of a big limitation, to have only global and
> > one level further ( local ) args, no per function
>
> One or more of your assumptions are wrong.
>
> Bash uses "dynamic scope" when it expands variables. This means that
> it looks first in the current functions local variables; if the variable
> isn't found there, it looks in the caller's local variables, and then
> in the caller's caller's local variables, and so on, until it reaches
> the global scope.
>
>
> f() {
> local var=set_in_f
> g
> }
>
> g() {
> echo "var is $var"
> }
>
> var=global
> f
> # Prints "var is set_in_f"
>
>
> 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:
>
> 1) They heard or read it somewhere, and did not verify it themselves.
>
> 2) They encountered a problem with their own program, and while attempting
>to track down the problem, they took a wrong turn, and did not fully
>diagnose the situation. They drew a wrong conclusion from partial data.
>
> In your case, I suspect it's #2.
>
> This project that you've been working on is so incredibly arcane,
> convoluted and bizarre that *nobody* understands it, including you. Who
> knows how many other fallacious assumptions are baked into it, since you
> are apparently incapable of simplifying anything down to the most basic
> level for debugging, or even explaining what your *goal* is.
>
[no subject]
The conditional variable not work in function in a script ie ~/.bashrc
while works in shell term.
$ unset u;h=0; o=(${h:+ ! -path "./*.txt"}) ;u=($u "${o[@]}"); c=(.
-regextype posix-extended "${b[@]}" -print); find "${c[@]}"
or type
$ k(){ unset u;h=0; o=(${h:+ ! -path "./*.txt"}) ;u=($u "${o[@]}");
c=(. -regextype posix-extended "${b[@]}" -print); find "${c[@]}" ;}
$ k
works
in a function k() in ~/.bashrc
k(){ unset u;h=0; o=(${h:+ ! -path "./*.txt"}) ;u=($u "${o[@]}"); c=(.
-regextype posix-extended "${b[@]}" -print); find "${c[@]}"
}
in output set -x:
+ unset u
+ h-0
+ o=(${h:+ ! -path "./*.txt"})
+ u=($u "${o[@]}")
+ c=(. -regextype posix-extended "${b[@]}" -print)
+ find . -regextype posix-extended ' ! -path ./*.txt' -print
find: paths must precede expression: ` ! -path ./*.txt'
Why and how to solve ?
Re:
On Mon, Mar 22, 2021 at 09:50:06AM +, Budi wrote:
> in a function k() in ~/.bashrc
>
> k(){ unset u;h=0; o=(${h:+ ! -path "./*.txt"}) ;u=($u "${o[@]}"); c=(.
> -regextype posix-extended "${b[@]}" -print); find "${c[@]}"
> }
>
> in output set -x:
>
> + unset u
> + h-0
This is clearly a falsehood. You didn't paste the actual output.
> + o=(${h:+ ! -path "./*.txt"})
> + u=($u "${o[@]}")
Why have the unquoted $u here when you know the variable is unset?
> + c=(. -regextype posix-extended "${b[@]}" -print)
What's in the array "b"? You never showed any such array.
> + find . -regextype posix-extended ' ! -path ./*.txt' -print
> find: paths must precede expression: ` ! -path ./*.txt'
>
> Why and how to solve ?
I think your real question is this one -- why did the exclamation point
and the word -path and the word ./*.txt all get squashed together into
a single word, instead of being inserted as three separate words?
If you can simplify your code down to *just* that case, and if you can
show an actual reproducer for it, then we might try to reproduce it
ourselves.
As it is now, I don't trust what you've written here, because you clearly
haven't been honest about it, and you haven't shown the actual commands
you ran ("set -x output" of what??), let alone the actual output.
Re: so-called pipe files (sh-np-*) do not get deleted when processes close.
On 3/20/21 3:15 PM, Michael Felt wrote: Scraping through this - thanks for the lessons aka explanations. On 18/03/2021 16:08, Chet Ramey wrote: On 3/18/21 5:53 AM, Michael Felt wrote: Yes, something to test. Thx. The ojdk scenario is: /usr/bin/printf > >(tee -a stdout.log) 2> >(tee -a stderr.log). So, yes, in this case it is working because printf is the parent - (which I never seemed to find actually calling open() of the file. It seems to be using the fd opened by the child - in a magical way). It's the redirection. The shell does the open, since the filename resulting from process substitution is the target of a redirection operator. This is a common idiom -- so common, in fact, that people have interpreted it to mean that the entire `> >(xxx)' is a single operator. However, the shell expands redirections in the child process it forks to exec printf, so that child shell is what does the process substitution. That might be the problem here. I think that ended up being the problem. When the process substitution is used in a redirection, and the command is a normal command found in the file system and executed with execve(2), there's nothing left to remove the FIFOs when the command completes. The best solution is for the shell to remove the FIFOs created as part of redirection (they've already been opened) before calling execve. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re:
On 3/22/21, Greg Wooledge wrote:
> On Mon, Mar 22, 2021 at 09:50:06AM +, Budi wrote:
>> in a function k() in ~/.bashrc
>>
>> k(){ unset u;h=0; o=(${h:+ ! -path "./*.txt"}) ;u=($u "${o[@]}"); c=(.
>> -regextype posix-extended "${b[@]}" -print); find "${c[@]}"
>> }
>>
>> in output set -x:
>>
>> + unset u
>> + h-0
>
> This is clearly a falsehood. You didn't paste the actual output.
>
>> + o=(${h:+ ! -path "./*.txt"})
>> + u=($u "${o[@]}")
>
> Why have the unquoted $u here when you know the variable is unset?
>
>> + c=(. -regextype posix-extended "${b[@]}" -print)
>
> What's in the array "b"? You never showed any such array.
>
>> + find . -regextype posix-extended ' ! -path ./*.txt' -print
>> find: paths must precede expression: ` ! -path ./*.txt'
>>
>> Why and how to solve ?
>
> I think your real question is this one -- why did the exclamation point
> and the word -path and the word ./*.txt all get squashed together into
> a single word, instead of being inserted as three separate words?
>
> If you can simplify your code down to *just* that case, and if you can
> show an actual reproducer for it, then we might try to reproduce it
> ourselves.
>
> As it is now, I don't trust what you've written here, because you clearly
> haven't been honest about it, and you haven't shown the actual commands
> you ran ("set -x output" of what??), let alone the actual output.
>
You're absolutely precisely correct!
messed up the real case with the transformed code one as it's in
hurry, here fixed simplified one:
unset b;u=7; o=(${u+ ! -path "./*.txt"}) ;b=($b "${o[@]}"); c=(.
-regextype posix-extended "${b[@]}" -print); find "${c[@]}"
absolutely work..
when deployed in a function in ~/.bashrc it failed as said
so confusing why, what the glitch causing it
ignoreeof variable (lowercase) as a synonym for IGNOREEOF
The lowercase 'ignoreeof' variable appears to act as a sort of a synonym to the uppercase 'IGNOREEOF'. Both seem to call into 'sv_ignoreeof', and the latter one set takes effect. I can't see the lowercase one documented anywhere, is this on purpose?
Re: ignoreeof variable (lowercase) as a synonym for IGNOREEOF
On 3/22/21 10:43 AM, Ilkka Virta wrote: The lowercase 'ignoreeof' variable appears to act as a sort of a synonym to the uppercase 'IGNOREEOF'. Both seem to call into 'sv_ignoreeof', and the latter one set takes effect. I can't see the lowercase one documented anywhere, is this on purpose? It exists only for backwards compatibility; it's deprecated and has been for years. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: so-called pipe files (sh-np-*) do not get deleted when processes close.
On 3/16/21 8:04 AM, Michael Felt wrote: Decided to give bash-5.1 a try. I doubt it is major, but I get as far as: "../../../src/bash-5.1.0/lib/sh/tmpfile.c", line 289.11: 1506-068 (W) Operation between types "char*" and "int" is not allowed. ld: 0711-317 ERROR: Undefined symbol: .mkdtemp ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more information. make: 1254-004 The error code from the last command is 8. I figured this out. There is a typo in config-bot.h that prevents USE_MKDTEMP from being disabled if configure doesn't find it. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
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 read, a complete, clear description of the situation. For instance, you give a complete, clear description: Bash uses "dynamic scope" when it expands variables. This means that it looks first in the current functions local variables; if the variable isn't found there, it looks in the caller's local variables, and then in the caller's caller's local variables, and so on, until it reaches the global scope. And that behavior is implied if you read the definition of "local" closely. But I couldn't find any text in the manual page that states that directly. (*Very* closely, as the text refers to "the function and its children". But function definitions don't nest; what it means is "the function *invocation* and its child invocations.) In principle it should be stated at the point where parameter expansion is introduced, as it is the *definition* of what parameter expansion does. Dale
Re: about the local not-on-every-function-separately var issue
On 3/22/21 9:38 PM, Dale R. Worley wrote: > 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 read, a complete, > clear description of the situation. For instance, you give a complete, > clear description: > > Bash uses "dynamic scope" when it expands variables. This means that > it looks first in the current functions local variables; if the variable > isn't found there, it looks in the caller's local variables, and then > in the caller's caller's local variables, and so on, until it reaches > the global scope. > > And that behavior is implied if you read the definition of "local" > closely. But I couldn't find any text in the manual page that states > that directly. It's described pretty plainly in FUNCTIONS. It even mentions dynamic scoping as an explicit term. "Ordinarily, variables and their values are shared between the function and its caller. If a variable is declared local, the variable's visible scope is restricted to that function and its children" It also finishes off its description by pointing out "When the function returns, the global variable is once again visible." > (*Very* closely, as the text refers to "the function and > its children". But function definitions don't nest; what it means is > "the function *invocation* and its child invocations.) Since you yourself felt the need to describe this as "nested" functions, not "child" functions, I'm curious why you thought nested functions as a source code paradigm is a better comparison than, say, parent/child processes as an invocation paradigm? python has nested functions. If I ever heard someone refer to a child function in python, I would not expect it to refer to nested functions -- I'd expect it to refer to the call stack. Going back to the previous definition I pointed out... note the explicit comparison of "caller" and "children" as opposites. > In principle it > should be stated at the point where parameter expansion is introduced, > as it is the *definition* of what parameter expansion does. I don't see what principle makes you think it should be removed from its current location, the description of functions (which is extremely relevant to function scoping) and moved to parameter expansion, which is currently all about the syntax rules non-local and local variables share. Which is still not the location where local is defined and described. -- Eli Schwartz Arch Linux Bug Wrangler and Trusted User OpenPGP_signature Description: OpenPGP digital signature
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 increment, which > is simply abominable.) And let's not forget the original "glob"! But my point is that using external programs to do minor processing tasks has a long history in shells. > but beyond a certain > point, trying to force a shell to act like a Real Programming Language > is just not reasonable. I've never tracked down why, but the Perl executable is a lot smaller than the Bash executable. So it's likely that turning a shell into a Real Programming Language is also likely to be unusually expensive. Dale
Redirection between assignment statement and command name prevents alias substitution
$ alias u=uname $ >&2 a=b u Linux $ >&2 u Linux $ a=b >&2 u No command u found, did you mean: ... In all three cases `u' is in a position where a command name may appear, and should be subjected to alias substitution. This is reproducible on devel too -- Oğuz
