Re: copy

[Dave Finlay]

Does the /data/test directory exist prior to execution?  Otherwise cp is
just copying the result set one at a time to a regular file at /data/test.

You may want to append a forward slash to the directory name, as that will
cause cp to error if the directory doesn't exist instead.  Or chain the
command after mkdir -p /output/dir.  That will error the same if it isn't a
directory, but also create it if it doesn't exist.  Since you are
interested in the files' timestamps, you may way to use --preserve to
preserve them.

So, something like this:

dest_dir='/data/test'; mkdir -p "${dest_dir}" && find . -type f -mtime +10
-name "*.txt" -exec cp --preserve {} "${dest_dir}" \;



Dave Finlay

On Thu, Feb 25, 2016 at 5:41 PM, Val Krem  wrote:

> Hi,
>
> I want to copy files which are older than 10 days  with the extension file
> name txt.
>
>
> I used the following  and it is not doing what supposed to do
>
>
> find . -type f -mtime +10 -name "*.txt" -exec cp {} /data/test \;
>
> can any one help me out?
>
>

Re: [minor] "precision" of $SECONDS

[Linda Walsh]

Stephane Chazelas wrote:

2016-02-25 03:03:41 -0800, Linda Walsh:

  

Stephane Chazelas wrote:


$ time bash -c 'while ((SECONDS < 1)); do :; done'
bash -c 'while ((SECONDS < 1)); do :; done'  0.39s user 0.00s system 99% cpu 
0.387 total
  


   Sorry I took "cpu xxx total" to be the total cpu time.  Silly me. 
(I do believe you, just the display format could be more clear).





  

Try:

TIMEFORMAT='%2Rsec %2Uusr %2Ssys (%P%% cpu)'



That would be for bash. In anycase, bash does already include
the elapsed time in its default time output like zsh.
  

---
but not as clearly, IMO... ;-)


But the problem here is not about the time keyword, but about the
$SECONDS variable.
  

---
   I realize that.

[...]
  

   With linux, one can read /proc/uptime to 100th's of a sec, or
use date to get more digits.  A middle of the road I used for
trace timing was something like:

function __age { declare ns=$(date +"%N"); declare -i
ms=${ns##+(0)}/100;
 printf "%4d.%03d\n" $SECONDS $ms
}


[...]

I'm not sure how that gives you the time since startup.
  

---
   The time since the bash script startup.
I was guessing that SECONDS recorded the integer value of 'seconds'
at the start of the script.  Thus it shows later times as the
later recorded time in seconds - the original time in seconds -- or
at least that would match current behavior -- initial "seconds"
param from gettime, (ignoring the nano or centi secs, depending on call).

going from an integer value of the time
at start

Currently, if bash is started at

00:00:00.7
  


   Well, ok, but time calls usually give back
seconds from 1970, with some giving back another param for
centi, or more modern calls giving back 2nd parm for nano's.

Theoretically, bash could never start when seconds=0, unless
it was started in 1970...  But I'm guessing you are using clock
time, whereas I was using the time from the start of the script.

I.e. @ start of script, SECONDS gets the # secs since 1970,
and (if done at the same time, the date call for nanosecs) would
be the #nanos above that number of secs.



After 0.4 seconds (at 00:00:01.1), $SECONDS will be 1 (the "bug"
I'm raising here). "ms" will be 100, so you'll print 1.100
instead of 0.600. And with my suggested fix, you'd print 0.100.
  

---
At bash startup, I'll see 0 seconds, and 7000,000 nanosecs.
after .4 secs, Ill see 1 sec & 1000,000 nanosecs.

So diff would be 1.1=0.7 = .4secs = correct answer, no?




Note that all of zsh, ksh93 and mksh have builtin support to get
elapsed time information with subsecond granularity.
  

That's not a POSIX requirement, and bash is hardly an ideal tool
to need or rely on sub-second granularity, especially since
it doesn't process signals in real-time, but only upon
a keypress in readline.

Re: [minor] "precision" of $SECONDS

[Stephane Chazelas]

2016-02-25 10:48:51 -0500, Chet Ramey:
[...]
> Because bash doesn't have floating point arithmetic.

Yes, makes sense. mksh having $EPOCHREALTIME floating point even
though it doesn't have floating point arithmetic does sound
weird.

Any plan of adding floating point arithmetic support to bash by
the way?

> There's no
> real reason to have $SECONDS in a format you can't use to perform
> calculations.

That could be done with an extra $NANOSECONDS variable, but then
that wouldn't be reliable as in now=$SECONDS.$NANOSECONDS,
$SECONDS and $NANOSECONDS could be expanded at different seconds
(if run for instance at 00:00:00.999).

A printf '%(sec=%s nsec=%N)T' -1 wouldn't have the problem though.

> Bash's %T implementation doesn't have %N because it uses the libc
> strftime(3), and as far as I know, no strftime provides it.  I assume
> that ksh93 implements it internally as part of libast.
[...]

Probably. Note that GNU date also has a %N and doesn't use
strftime either. strftime taking a struct tm can't have
subseconds anyway.

-- 
Stephane

Re: [minor] "precision" of $SECONDS

[Chet Ramey]

On 2/25/16 8:18 AM, Stephane Chazelas wrote:

> Similar features would be welcome in bash.
> 
> bash has "times" that gives you CPU time with sub-second
> granularity. It's got a "printf %T" a la ksh93, but no %N, its
> $SECOND is only integer (and currently has that issue discussed
> here).

Because bash doesn't have floating point arithmetic.  There's no
real reason to have $SECONDS in a format you can't use to perform
calculations.

Bash's %T implementation doesn't have %N because it uses the libc
strftime(3), and as far as I know, no strftime provides it.  I assume
that ksh93 implements it internally as part of libast.

Bash doesn't have a `sleep' builtin at all, but there is a loadable
sleep builtin that offers sub-second granularity.

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/

Re: Bash-4.4-beta available for FTP

[Chet Ramey]

On 2/25/16 8:34 AM, Michael Felt wrote:
> AIX is "no more entitled" to it, but they are using it - and "it" is
> stopping make from succeeding.

You're still using the version of bash that you reported on originally.
Try the just-released bash-4.4-rc1 instead.

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/

Re: Bash-4.4-beta available for FTP

[Michael Felt]

AIX is "no more entitled" to it, but they are using it - and "it" is
stopping make from succeeding.

+  > .buildaix/make.out
../src/bash-4.4/parse.y: warning: 1 shift/reduce conflict [-Wconflicts-sr]
"../src/bash-4.4/execute_cmd.c", line 4655.16: 1506-068 (W) Operation
between types "struct array*" and "volatile struct array*" is not allowed.
"../src/bash-4.4/execute_cmd.c", line 4657.16: 1506-068 (W) Operation
between types "struct array*" and "volatile struct array*" is not allowed.
"/usr/include/mbstr.h", line 47.22: 1506-334 (S) Identifier mbchar_t has
already been defined on line 175 of "../src/bash-4.4/include/shmbchar.h".
make: 1254-004 The error code from the last command is 1.

This is from a build done from the beta release from 24 hours ago.

Michael

On Mon, Oct 26, 2015 at 4:40 PM, Chet Ramey  wrote:

> On 10/23/15 1:50 PM, Michael Felt wrote:
> > I do not mind installing yacc :)
>
> You would need to install bison anyway.
>
> > How about the redefine of mbchar_t ?
>
> See my previous reply; AIX is no more entitled to this symbol than anyone
> else.  Bash doesn't actually use this symbol internally, since it only uses
> some of the functions from the gnulib implementation, so I imagine I could
> just excise it from the header file if I had to.
>
> Chet
> --
> ``The lyf so short, the craft so long to lerne.'' - Chaucer
>  ``Ars longa, vita brevis'' - Hippocrates
> Chet Ramey, ITS, CWRUc...@case.edu
> http://cnswww.cns.cwru.edu/~chet/
>

Re: [minor] "precision" of $SECONDS

[Linda Walsh]

Stephane Chazelas wrote:

$ time bash -c 'while ((SECONDS < 1)); do :; done'
bash -c 'while ((SECONDS < 1)); do :; done'  0.39s user 0.00s system 99% cpu 
0.387 total

That can take in between 0 and 1 seconds. Or in other words,
$SECONDS becomes 1 in between 0 and 1 second after the shell was
started.

The format you are using to display output of 'time' doesn't show
real time -- only CPU seconds.

Try:

TIMEFORMAT='%2Rsec %2Uusr %2Ssys (%P%% cpu)'

It shows the real, "clock" time, as well as
the standard % formula of cpu-secs/real-secs -- which can give
up to #Cores x 100"%" as value for %cpu  stretches the standard
def of "percent", but is at least more honest than grouping
all cpu's together as "1 cpu", and showing 100% usage of 1 core
on a 12-core machine as "8.3%".



mksh and zsh behave like bash (I'll raise the issue there as
well).

With zsh (like in ksh93), one can do "typeset -F SECONDS" to
make $SECONDS floating point, which can be used as a work around
of the "issue".
  


   With linux, one can read /proc/uptime to 100th's of a sec, or
use date to get more digits.  A middle of the road I used for
trace timing was something like:

function __age { declare ns=$(date +"%N"); declare -i 
ms=${ns##+(0)}/100;

 printf "%4d.%03d\n" $SECONDS $ms
}
Then I add that in my PS4 prompt:
## for *relative* script exec speed, only!
##   (slows down normal speed significantly):
#export 
PS4='>[$(__age)]${BASH_SOURCE:+${BASH_SOURCE[0]/$HOME/\~}}#${LINENO}${FUNCNAME:+(${FUNCNAME[0]})}> 
'


On cygwin, calling 'date' was a deal breaker, so I just used /proc/uptime
to get the relative time down to centiseconds. 


As you can see, I wanted the times
relative to the start of a given script, thus used SECONDS for that.

Given the overhead of calling 'date', the times printed are easily 
20-50x slower

than w/o the time -- BUT, as the comment says above, it's good for
determining relative differences -- not only times for each command, but
also algorithmic differences, as the overhead is relatively constant.

Translation of the Bash Reference Manual - edition 4.3, into Brazilian Portuguese language [ANNOUNCEMENT]

[Jamenson Ferreira Espindula de Almeida Melo]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256



Jaboatão dos Guararapes, Pernambuco, Brazil, 25 February 2016.




Subject: Translation of the Bash Reference Manual - edition 4.3 -
version 4.3, 2 February 2014, into Brazilian Portuguese language
[ANNOUNCEMENT]




I am glad to announce that I have finished the translation of the Bash
Reference Manual - edition 4.3 - version 4.3, 2 February 2014
into Brazilian Portuguese (pt_BR) language.

All the project's files are under the terms of The GNU Free
Documentation License, Version 1.3, 3 November 2008, or any later
version published by the Free Software Foundation.




Help need to propagate this announcement and to put the documentation
into big GNU/Linux Distributions like Debian GNU/Linux, Slackware Linux,
Ubuntu, and so on.




The files are at GitHub:

git clone https://github.com/espindula/bashref-pt_BR.git




There already are four (04) kinds of formats: Plaintext; PDF; HTML; e
GNU Texinfo.




Thank you in advance.



Jamenson Ferreira Espindula de Almeida Melo
GNU/Linux user # 166197
https://linuxcounter.net/cert/166197.png

Key fingerprint:
234D 1914 4224 7C53 BD13  6855 2AE0 25C0 08A8 6180


-BEGIN PGP SIGNATURE-
Version: GnuPG v2.1.4 (GNU/Linux)

iQEcBAEBCAAGBQJWzr8mAAoJECrgJcAIqGGAy7sH/1OY0b7TCYELppcKSb2xVMxb
ORhC6ZcMdCzvjOgRIQV3FltwPH9Diijie0WKhEhjvFVZkxfEOjIJ9orRYdQGrf0E
cRDzw7puupY8AWcT6Yv+sX+3P+1PGKx08MfJmFhKiWdOfBwvEX11xAD7bc6TQxWz
X7LOOmkZsVDm1O4Vbmpv5uH1JpKwS9nfovqMglZDQMbOqsBH+baJuxwQ17Gkj08O
2USanHYbZeKaSq92NTtlcxB2xgdCqpq5UHso3YuDw6PoPQyIin/BJ1TG6SX9a12/
fYI7W1XhRdBqnuTncJUj1RuEbvLfAxmCjmDyAG+3+qZgbWz2w3kARxn1R1PzfIs=
=HA/3
-END PGP SIGNATURE-