Re: I think bash logic in a loop like : while [ condition] |read somevar is flawed.
* **=>which read** **which: no read in (/sbin:/usr/sbin:/usr/local/sbin:/root/bin:/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/X11R6/bin:/usr/games:/opt/kde3/bin)** **3 *read is a built in. there is no subshell. any way, it seems then to me that even IF "read" was a subshell, the scope of that would start and end with the read statement. as you can see, it is not true. it extends to the scope of the entire while loop, as the "echo cval" statements demonstrate thus, magically read in the subshell is making while a part of it's own shell ??? there is no "while|read" command, you see. so "while" also invokes a shell ? that magically can do which you think is not possible ?? because it is then the parent, not a child, evidently ? please explain.. Really, all other programming languages propagate variables from children to parents? I find that hard to believe. that makes no sense. there is no read command in my path. so, with that out of the way, what is your comment ? On 12/24/13 08:04, Chris Down wrote: On 2013-12-23 23:57:32 +0100, rens wrote: Hello, this script: ___ export cval=0 echo entering while # listing ten files, to generate some output to count. ls -1 /usr/bin|head -10 |while read fname Just use a `for` loop and a glob. Really. It's that easy. do cval=$(( cval +1 )) echo cval = $cval file = $fname done # one would think cval is now 10. but it is not, contrary to any other programming language Really, all other programming languages propagate variables from children to parents? I find that hard to believe. that makes no sense. Yes, it does. You created a subshell. How do you expect for the variable to propagate back to the parent, where you are expanding it? Please Don't bother to tell me it s the way you guys think it should technically work. I know you think something along those lines, at least thats what I am told Don't use a subshell if you don't want one. However, no one in this world having to solve real life issues with software, is interested in how it technically works. we need real life logic and software that can deal with real life challenges and requirements. Then stop using a subshell. Bash should not work that way. no programming language handles logic this way. Not pascal, korn shell, c shell, cobol, c, c++, lua , fortran or any other language i ever used. None of the languages you listed propagate variables from children to parents directly. I don't know why you think you should have that variable in the parent when you populated it in a subshell...
Re: I think bash logic in a loop like : while [ condition] |read somevar is flawed.
On 2013-12-24 09:25:05 +0100, rens wrote: > *read is a built in. there is no subshell. $ echo "$BASHPID"; : | echo "$BASHPID" 26269 26271 > any way, it seems then to me that even IF "read" was a subshell, the scope > of that would start and end with the read statement. I don't know why you think that. > thus, magically read in the subshell is making while a part of it's own > shell ??? No, the pipe is. > there is no "while|read" command, you see. > > so "while" also invokes a shell ? that magically can do which you think is > not possible ?? > because it is then the parent, not a child, evidently ? > > please explain.. The pipe creates the subshell. > there is no read command in my path. > > so, with that out of the way, what is your comment ? What does `read` have to do with anything? pgpp28tGIJENF.pgp Description: PGP signature
Re: I think bash logic in a loop like : while [ condition] |read somevar is flawed.
Mr Down, you are a master at evading the issue. and therefore, i.m.h.o, completely useless as a programmer. If you try explain your statements about scope to yourself. you do risk to end up in a endless loop of your own making. I wish you a merry christmas. On 12/24/13 09:29, Chris Down wrote: On 2013-12-24 09:25:05 +0100, rens wrote: *read is a built in. there is no subshell. $ echo "$BASHPID"; : | echo "$BASHPID" 26269 26271 any way, it seems then to me that even IF "read" was a subshell, the scope of that would start and end with the read statement. I don't know why you think that. thus, magically read in the subshell is making while a part of it's own shell ??? No, the pipe is. there is no "while|read" command, you see. so "while" also invokes a shell ? that magically can do which you think is not possible ?? because it is then the parent, not a child, evidently ? please explain.. The pipe creates the subshell. there is no read command in my path. so, with that out of the way, what is your comment ? What does `read` have to do with anything?
Re: I think bash logic in a loop like : while [ condition] |read somevar is flawed.
On 2013-12-24 10:16:28 +0100, rens wrote: > you are a master at evading the issue. > > and therefore, i.m.h.o, completely useless as a programmer. You appear to have become confused into thinking that I have an interest in helping people that do not want to listen or learn. I apologise if I misled you into thinking that -- on the contrary, I have absolutely no interest in helping you after your oddly inflammatory, willfully ignorant, and barely intelligible postings to this list. I am just trying to prevent your sewage from spewing into the mind of anyone else but yourself. Here's a tip: if you want people to sincerely help in future, maybe you would consider not being a massive jackass when trying to make a first impression. Please go read this: http://www.catb.org/~esr/faqs/smart-questions.html Merry Christmas. :-) pgpBLZsz86CZv.pgp Description: PGP signature
Re: I think bash logic in a loop like : while [ condition] |read somevar is flawed.
On Mon, Dec 23, 2013 at 11:57:32PM +0100, rens wrote: > ls -1 /usr/bin|head -10 |while read fname > do > cval=$(( cval +1 )) > echo cval = $cval file = $fname > done > # one would think cval is now 10. but it is not, contrary to any other > programming language > > echo " after while: cval = $cval" > ___ > > does not set the value of cval after exiting the while loop. The pipe creates subshells, so your entire while loop is running in a subshell (a child process). Changes to variables inside the loop will not persist once the subshell terminates. http://mywiki.wooledge.org/BashFAQ/024 explains the issue in more detail, and provides alternatives. I'm sorry that other people did not explain the issue usefully.
Re: I think bash logic in a loop like : while [ condition] |read somevar is flawed.
On Tue, Dec 24, 2013 at 07:49:28PM +0100, rens wrote: > I understand the technical origin of the behaviour. > Spend +25 yrs in unix. I am so old, that I remember fighting (at my > 40th) with linux 0.79, I think > > However, I am questioning if this is what a programming language should do. Stop thinking of bash as a programming language. It is a command shell. Pipelines invoke multiple processes simultaneously. That's their purpose: to run a bunch of things in parallel, with linked input/output. Each process is just that -- a process. A full-blown separate running program with its own PID, its own private memory and file descriptors, and so on. Moreover, the behavior of bash is constrained by 40+ years of unix shell history. It implements the feature set specified by POSIX, as well as doing its best to be backwards compatible with older versions of itself, and to a much smaller extent, with ksh and sometimes even csh. If you want a shell that breaks out of that mold and does things in a new way, then perhaps you want zsh. If you want an interpreted programming language instead of a shell, there are a bunch to choose from.
Re: Lengthy working dir (\w) breaks wrapping in a multi line coloured PS1 prompt
Use something to trim your prompt usefully (or rigidly like bash prompt builtin
'\w'):
--- in your .bashrc define these:
# return a shorted path when displayed path would take up > 50% width of screen
alias int=declare\ -i _e=echo _pf=printf exp=export ret=return
exp __dpf__='local -a PF=(
"/$1/$2/$3/../\${$[$#-1]}/\${$#}"
"/$1/$2/../\${$[$#-1]}/\${$#}"
"/$1/../\${$[$#-1]}/\${$#}"
"/$1/../\${$#}"
".../\${$#}"
"..." )'
function spwd () { \
(($#)) || { _e "spwd called with null arg"; return 1; }; \
int w=COLUMNS/2 ;\
( _pf -v _p "%s" "$1" ; export IFS=/;\
set $_p; shift; unset IFS ;\
t="${_p#${HOME%${USER}}}" ;\
int tl=${#t} ;\
if (($#<=6 && tlPS1='\[$(titlebar)'"$_prompt_open"'\]${HOSTNAME}:$(spwd
"$PWD")'"$_prompt"'\['"$_prompt_close"'\] '
fi
--
cd
"/tmp/a_long_directory_name/getting_even_bigger_so_that_I_can_test/this_prompt_is_working_fine_or_not"
Observe that the prompt is now displayed as:
Ishtar:.../this_prompt_is_working_fine_or_not>
Notice it doesn't take more than half the width of your screen..
It only displays host if you are logged in remotely (relies on REMOTEHOST being
set
via pam_env.dll)
Re: I think bash logic in a loop like : while [ condition] |read somevar is flawed.
rens wrote:
this script:
___
export cval=0
echo entering while
# listing ten files, to generate some output to count.
ls -1 /usr/bin|head -10 |while read fname
do
cval=$(( cval +1 ))
echo cval = $cval file = $fname
done
# one would think cval is now 10. but it is not, contrary to any other
programming language
echo " after while: cval = $cval"
___
does not set the value of cval after exiting the while loop.
that makes no sense.
Bash should not work that way. no programming language handles logic
this way. Not pascal, korn shell, c shell, cobol, c, c++, lua , fortran
or any other language i ever used.
Bash is a command-line interpreter. It is not a language;
It accepts commands and has ways of sequencing commands and funneling
output from one command to the next.
Korn shell works the same way. csh has no read builtin that I can
find, so you can't write the program the same way.
Every time you use "|", you are ending the previous program and piping results
to another program.
The above is equal to the *first* 'while' output in the program below:
If you want your progam to work right, you need to have the count be in your
shell, and NOT have any "|" in the invocation line (i used < <(...))
The below produces the wrong output first (cval=0) and then runs it again with
the commands re-arranged to not use '|' -- which produces the right value.
Does this help you understand what's going on?
-
#!/bin/bash
shopt -s expand_aliases
alias program=function
alias int=declare\ -i
alias my=declare
program myhead {
my inp=${1:-10}
if [[ ${inp:0:1} == - ]]; then inp="${inp:1}"; fi
int lines=$inp
while ((lines-- > 0)); do
my line
read line
echo "$line"
done
}
declare -xi cval=0
echo entering while
program print_exported_cval {
while [[ ! $(typeset -p cval |sed -r 's/ +/\t/g'|cut -f2) =~ x ]];do
unset cval
done
echo -n "exported_cval=$cval, "
}
program number {
#int cval=$cval
while read fname; do
cval=$cval+1
echo -n "local_cval=$cval, "
(print_exported_cval)
echo "file = $fname"
done
}
#number< <(ls -1 | myhead -10 )
ls -1 | myhead -10 |number
echo " after 1st while: cval = $cval"
number< <(ls -1 | myhead -10 )
echo " after 1st while: cval = $cval"
#end script -
Re: I think bash logic in a loop like : while [ condition] |read somevar is flawed.
On Tue, Dec 24, 2013 at 8:56 PM, Greg Wooledge wrote: > On Tue, Dec 24, 2013 at 07:49:28PM +0100, rens wrote: > > I understand the technical origin of the behaviour. > > Spend +25 yrs in unix. I am so old, that I remember fighting (at my > > 40th) with linux 0.79, I think > > > > However, I am questioning if this is what a programming language should > do. > > Stop thinking of bash as a programming language. It is a command shell. > > Pipelines invoke multiple processes simultaneously. That's their purpose: > to run a bunch of things in parallel, with linked input/output. Each > process is just that -- a process. A full-blown separate running program > with its own PID, its own private memory and file descriptors, and so on. > > Moreover, the behavior of bash is constrained by 40+ years of unix shell > history. It implements the feature set specified by POSIX, as well as > doing its best to be backwards compatible with older versions of itself, > and to a much smaller extent, with ksh and sometimes even csh. > > If you want a shell that breaks out of that mold and does things in a > new way, then perhaps you want zsh. > > If you want an interpreted programming language instead of a shell, > there are a bunch to choose from. > > If I remember correctly, POSIX allows the lastpipe behaviour. As far as not explaining the behaviour, mr rens clearly said he was not interested in any kind of understanding.
