Re: copy
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
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
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
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
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: [minor] "precision" of $SECONDS
2016-02-25 13:18:17 +, Stephane Chazelas:
[...]
> > 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.
> Currently, if bash is started at
>
> 00:00:00.7
>
> 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.
0.400
Sorry, meant 0.400 above.
--
Stephane
Re: Bash-4.4-beta available for FTP
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
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
> >
> >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.
It does. The last number (0.387 total) is the elapsed time in
the output of zsh (my interactive shell)'s "time" keyword. CPU
times are 0.39s user and 0.00s system totalling to 0.39s
Because it's a busy loop, CPU time is close to 100% (99%) so
elapsed and CPU time are roughly the same.
> 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 the problem here is not about the time keyword, but about the
$SECONDS variable.
[...]
>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.
Currently, if bash is started at
00:00:00.7
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.
[...]
> As you can see, I wanted the times
> relative to the start of a given script, thus used SECONDS for that.
Note that all of zsh, ksh93 and mksh have builtin support to get
elapsed time information with subsecond granularity.
zsh has:
- $SECONDS: time since shell start. floating point after
typeset -F SECONDS
- $EPOCHSECONDS (unix time) (in zsh/datetime module)
- $EPOCHREALTIME: same as floating point
- zselect builtin to sleep with 1/100s granularity
(in zsh/zselect module)
- the "time" keyword, without a command prints CPU and real
time for the shell and waited-for ancestors (and other
getrusage statistics you can add with TIMEFMT)
ksh93 has:
- $SECONDS: time since shell start. floating point after
typeset -F SECONDS
- EPOCHREALTIME=$(printf '%(%s.%N)T' now) for unix time as a
float (note that you need a locale where the decimal
separator is a period to be able to use that in ksh
arithmetic expressions, or you need to replace that "." with
a "," above).
- builtin sleep with sub-second granularity
mksh has:
- $EPOCHREALTIME: unix time as floating point (note however
that mksh doesn't support floating point arithmetic).
- builtin "sleep" command with sub-second granularity.
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).
It does supports a $TMOUT with sub-second granularity though.
You can use that to sleep for sub-second durations if you find a
blocking file to read from. On Linux, that could be:
TMOUT=0.4 read < /dev/fd/1 | :
but that still means forking processes.
--
Stephane
Re: [minor] "precision" of $SECONDS
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]
-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-
