cmd completion.. normal that it doesnt complete dirs when cmds are available ?
i have a dir with some xbl*/ dirs and few xbl* commands ( via $PATH ) i tried there xbl,tabtab but it only completed cmds is this desired ? snip 2021-11-12 , Fri Nov , 18:17:56.530771 == 1636741076.530771 # root:0:0 # @ /dev/pts/1 ( 0 ) localhost -> /root/e xblsslfile/ xblfiletransfer/ xblgawk2bash/ xblasone/ xblhelp/ xblcountexts/ xblgl/ xblauth/ xblstarter/ xblask/ xbldemo/ xblskelempty/ xblmapencdec/ xblencdec/ xblhttpd/ xblcmdlineshorts/ off/ xbldebian/ xblps1/ phttp/ sysrcs/ prhttp/ xblbashrc.xmb xblbashrc.2 xblbashrc xblbashrc.install xbl xbl xbl.files.gawk xbl.gawkxblunpackxbl 0 exit // 70927s old , static
Re: bash conditional expressions
FILE1 -nt FILE2 True if file1 is newer than file2 (according to modification date). 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."
Re: bash conditional expressions
On Fri, Nov 12, 2021 at 02:21:15PM +0100, Mischa Baars wrote: > It is how my makefiles work :) Then they aren't Makefiles. They're BaarsBuilder files or something. > Do you realize how much time it takes to load the stat executable on all > source files [...] What the hell. You're writing your own build tool IN BASH using stat(1) and other external commands? WHY do people do this to themselves?
Re: bash conditional expressions
Yeeh, that's funny indeed :) Now this: time ( test2Y=$(stat -c %Y test2); for (( i=0; i<1024; i++ )); do if (( $(stat -c %Y test1) < ${test2Y} )); then echo >> /dev/null; else echo >> /dev/null; fi; done; ); real0m4.503s user0m1.048s sys 0m3.240s time ( for (( i=0; i<1024; i++ )); do if [[ -N test1 ]]; then echo >> /dev/null; else echo >> /dev/null; fi; done; ); real0m0.034s user0m0.023s sys 0m0.009s On Fri, 2021-11-12 at 12:16 -0500, Lawrence Velázquez wrote: > On Fri, Nov 12, 2021, at 4:36 AM, Mischa Baars wrote: > > Using Fedora 32 (bash 5.0.17) this returns a true, while on Fedora 35 (bash > > 5.1.8) this returns a false: > > touch test; if [[ -N test ]]; then echo true; else echo false; fi; > > > > [...] > > > > As I understand it, -N stands for NEW and therefore should return a true > > when either a 'touch -a test' or a 'touch -am test' is given. > > FWIW, there's some disagreement on this. > > % cat foo_test > test -N foo > echo "$?" > % touch foo > % /bin/bash -c 'echo "$BASH_VERSION"; . ./foo_test' > 3.2.57(1)-release > 0 > % /opt/local/bin/bash -c 'echo "$BASH_VERSION"; . ./foo_test' > 5.1.8(1)-release > 1 > % ksh -c 'echo "${.sh.version}"; . ./foo_test' > Version AJM 93u+ 2012-08-01 > 1 > % yash -c 'echo "$YASH_VERSION"; . ./foo_test' > 2.51 > 1 > % zsh -c 'echo "$ZSH_VERSION"; . ./foo_test' > 5.8 > 0 >
Re: bash conditional expressions
On Fri, Nov 12, 2021, at 4:36 AM, Mischa Baars wrote: > Using Fedora 32 (bash 5.0.17) this returns a true, while on Fedora 35 (bash > 5.1.8) this returns a false: > touch test; if [[ -N test ]]; then echo true; else echo false; fi; > > [...] > > As I understand it, -N stands for NEW and therefore should return a true > when either a 'touch -a test' or a 'touch -am test' is given. FWIW, there's some disagreement on this. % cat foo_test test -N foo echo "$?" % touch foo % /bin/bash -c 'echo "$BASH_VERSION"; . ./foo_test' 3.2.57(1)-release 0 % /opt/local/bin/bash -c 'echo "$BASH_VERSION"; . ./foo_test' 5.1.8(1)-release 1 % ksh -c 'echo "${.sh.version}"; . ./foo_test' Version AJM 93u+ 2012-08-01 1 % yash -c 'echo "$YASH_VERSION"; . ./foo_test' 2.51 1 % zsh -c 'echo "$ZSH_VERSION"; . ./foo_test' 5.8 0 -- vq
Re: coproc does not work with a lower case variable name
On 11/11/21 11:09 PM, g...@as.lan wrote: Bash Version: 5.1 Patch Level: 8 Release Status: release Description: coproc gives a syntax error if I try to use it with a lower case variable name and a compound command: bash: syntax error near unexpected token `}' bash: syntax error near unexpected token `(' Repeat-By: coproc bc { bc; } coproc bc (bc) I can't reproduce this. What does `type bc' produce? -- ``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: coproc does not work with a lower case variable name
never seen, and i never coproc uppercase i suspect your bc is a half complex alias On Fri, Nov 12, 2021, 15:29 wrote: > Configuration Information [Automatically generated, do not change]: > Machine: x86_64 > OS: linux-gnu > Compiler: gcc > Compilation CFLAGS: -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector-strong > -funwind-tables -fasynchronous-unwind-tables -fstack-clash-protection > -Werror=return-type -flto=auto -g -D_GNU_SOURCE -DRECYCLES_PIDS -Wall -g > -Wuninitialized -Wextra -Wno-switch-enum -Wno-unused-variable > -Wno-unused-parameter -Wno-parentheses -ftree-loop-linear -pipe > -DBNC382214=0 -DIMPORT_FUNCTIONS_DEF=0 > uname output: Linux as.lan 5.14.14-1-default #1 SMP Thu Oct 21 05:05:03 > UTC 2021 (2b5383f) x86_64 x86_64 x86_64 GNU/Linux > Machine Type: x86_64-suse-linux-gnu > > Bash Version: 5.1 > Patch Level: 8 > Release Status: release > > Description: > coproc gives a syntax error if I try to use it with a lower case > variable name and a compound command: > bash: syntax error near unexpected token `}' > bash: syntax error near unexpected token `(' > > > Repeat-By: > coproc bc { bc; } > coproc bc (bc) > >
coproc does not work with a lower case variable name
Configuration Information [Automatically generated, do not change]: Machine: x86_64 OS: linux-gnu Compiler: gcc Compilation CFLAGS: -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector-strong -funwind-tables -fasynchronous-unwind-tables -fstack-clash-protection -Werror=return-type -flto=auto -g -D_GNU_SOURCE -DRECYCLES_PIDS -Wall -g -Wuninitialized -Wextra -Wno-switch-enum -Wno-unused-variable -Wno-unused-parameter -Wno-parentheses -ftree-loop-linear -pipe -DBNC382214=0 -DIMPORT_FUNCTIONS_DEF=0 uname output: Linux as.lan 5.14.14-1-default #1 SMP Thu Oct 21 05:05:03 UTC 2021 (2b5383f) x86_64 x86_64 x86_64 GNU/Linux Machine Type: x86_64-suse-linux-gnu Bash Version: 5.1 Patch Level: 8 Release Status: release Description: coproc gives a syntax error if I try to use it with a lower case variable name and a compound command: bash: syntax error near unexpected token `}' bash: syntax error near unexpected token `(' Repeat-By: coproc bc { bc; } coproc bc (bc)
coproc does not work with a lower case variable name
Configuration Information [Automatically generated, do not change]: Machine: x86_64 OS: linux-gnu Compiler: gcc Compilation CFLAGS: -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector-strong - funwind-tables -fasynchronous-unwind-tables -fstack-clash-protection - Werror=return-type -flto=auto -g -D_GNU_SOURCE -DRECYCLES_PIDS -Wall -g - Wuninitialized -Wextra -Wno-switch-enum -Wno-unused uname output: Linux as.lan 5.14.14-1-default #1 SMP Thu Oct 21 05:05:03 UTC 2021 (2b5383f) x86_64 x86_64 x86_64 GNU/Linux Machine Type: x86_64-suse-linux-gnu Bash Version: 5.1 Patch Level: 8 Release Status: release Description: coproc gives a syntax error if I try to use it with a lower case variable name and a compound command: bash: syntax error near unexpected token `}' bash: syntax error near unexpected token `(' Repeat-By: coproc bc { bc; } coproc bc (bc)
Re: bash conditional expressions
On Fri, Nov 12, 2021 at 3:22 PM Mischa Baars wrote: > It is how my makefiles work :) > Sounds to me you're not using Make, but some self-made tool, so the files you have would be more properly called build scripts or whatever, and not makefiles.
Re: bash conditional expressions
i suggest a bash only makefile script then that spawns few instances of whatever only, i do such whatever overall systems a find printf to comparement is fairly fast, to estimate new files then a good gcc in one cmd done On Fri, Nov 12, 2021, 14:22 Mischa Baars wrote: > Hi Greg, > > It is how my makefiles work :) > > Do you realize how much time it takes to load the stat executable on all > source files and object files? Conditional expressions are already in > memory. I prefer using the mtime field, the atime field and conditional > expressions. > > Mischa. > > > On Fri, Nov 12, 2021 at 1:25 PM Greg Wooledge wrote: > > > On Fri, Nov 12, 2021 at 10:36:01AM +0100, Mischa Baars wrote: > > > All of my makefiles only compile source files and link object files > that > > > are NEW, as in the modification timestamp is newer than OR EQUAL TO the > > > access timestamp, > > > > That's not how Makefiles work. > > > > Makefiles compare the mtimes of two files against each other. Source > > and target. If the source's mtime is greater than the target's mtime, > > then the target needs to be rebuilt. > > > > Most Linux distributions these days are disabling or half-disabling > > the atime field at the file system mount-option level, because of the > > tremendous inefficiency and wear on disks that it creates. > > > > >
Re: bash conditional expressions
Hi Greg, It is how my makefiles work :) Do you realize how much time it takes to load the stat executable on all source files and object files? Conditional expressions are already in memory. I prefer using the mtime field, the atime field and conditional expressions. Mischa. On Fri, Nov 12, 2021 at 1:25 PM Greg Wooledge wrote: > On Fri, Nov 12, 2021 at 10:36:01AM +0100, Mischa Baars wrote: > > All of my makefiles only compile source files and link object files that > > are NEW, as in the modification timestamp is newer than OR EQUAL TO the > > access timestamp, > > That's not how Makefiles work. > > Makefiles compare the mtimes of two files against each other. Source > and target. If the source's mtime is greater than the target's mtime, > then the target needs to be rebuilt. > > Most Linux distributions these days are disabling or half-disabling > the atime field at the file system mount-option level, because of the > tremendous inefficiency and wear on disks that it creates. > >
Re: bash conditional expressions
On Fri, Nov 12, 2021 at 10:36:01AM +0100, Mischa Baars wrote: > All of my makefiles only compile source files and link object files that > are NEW, as in the modification timestamp is newer than OR EQUAL TO the > access timestamp, That's not how Makefiles work. Makefiles compare the mtimes of two files against each other. Source and target. If the source's mtime is greater than the target's mtime, then the target needs to be rebuilt. Most Linux distributions these days are disabling or half-disabling the atime field at the file system mount-option level, because of the tremendous inefficiency and wear on disks that it creates.
Re: bash conditional expressions
> I agree that the `mtime >= atime' behavior should be restored; ``file > is newly created or was accessed since last modified'' is not a useful > information, nor is the opposite. Or, -N can be split into -A (atime > mtime) and -M (mtime > atime), and everyone would be happy :D
Re: bash conditional expressions
On Fri, Nov 12, 2021 at 12:44 PM Mischa Baars wrote: > Using Fedora 32 (bash 5.0.17) this returns a true, while on Fedora 35 (bash > 5.1.8) this returns a false: > touch test; if [[ -N test ]]; then echo true; else echo false; fi; This seems to have changed as a result of this bug report: https://lists.gnu.org/archive/html/bug-bash/2019-07/msg00022.html > > This means that newly created object files are no longer recognized by the > compile scripts as new object files and executables are no longer linked > against these new object files. > > Could you please restore the Fedora 32 behaviour? Someone must have read > the bash manual a little too precise, because now the statement only > returns true when a 'touch -a test' is given and not when a 'touch -am > test' is given. I agree that the `mtime >= atime' behavior should be restored; ``file is newly created or was accessed since last modified'' is not a useful information, nor is the opposite.
Re: bash conditional expressions
On Nov 12 2021, Mischa Baars wrote: > Using Fedora 32 (bash 5.0.17) this returns a true, while on Fedora 35 (bash > 5.1.8) this returns a false: > touch test; if [[ -N test ]]; then echo true; else echo false; fi; What does `stat test' print respectively? 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."
bash conditional expressions
Hi All, All of my makefiles only compile source files and link object files that are NEW, as in the modification timestamp is newer than OR EQUAL TO the access timestamp, such that when I include a new source file into a project or produce a new object file during compilation of the project, it does not take more time than required. I have two different versions of Fedora running here, Fedora 32 and Fedora 35. Using Fedora 32 (bash 5.0.17) this returns a true, while on Fedora 35 (bash 5.1.8) this returns a false: touch test; if [[ -N test ]]; then echo true; else echo false; fi; This means that newly created object files are no longer recognized by the compile scripts as new object files and executables are no longer linked against these new object files. Could you please restore the Fedora 32 behaviour? Someone must have read the bash manual a little too precise, because now the statement only returns true when a 'touch -a test' is given and not when a 'touch -am test' is given. As I understand it, -N stands for NEW and therefore should return a true when either a 'touch -a test' or a 'touch -am test' is given. In my opinion it is the manual page that should have been updated, and not the bash response to a -N conditional expression. Looking forward to a fix! Best regards, Mischa Baars.