cmd completion.. normal that it doesnt complete dirs when cmds are available ?

2021-11-12 Thread Alex fxmbsw7 Ratchev
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

2021-11-12 Thread Andreas Schwab
  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

2021-11-12 Thread Greg Wooledge
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

2021-11-12 Thread Michael J. Baars
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

2021-11-12 Thread Lawrence Velázquez
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

2021-11-12 Thread Chet Ramey

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

2021-11-12 Thread Alex fxmbsw7 Ratchev
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

2021-11-12 Thread gd
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

2021-11-12 Thread Grósz Dániel
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

2021-11-12 Thread Ilkka Virta
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

2021-11-12 Thread Alex fxmbsw7 Ratchev
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

2021-11-12 Thread Mischa Baars
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

2021-11-12 Thread Greg Wooledge
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

2021-11-12 Thread Oğuz
> 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

2021-11-12 Thread Oğuz
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

2021-11-12 Thread Andreas Schwab
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

2021-11-12 Thread Mischa Baars
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.