How to find all files between midnight and 08.00 am?

Hi,

Question: How to find all files between midnight and 08.00 am? How is
it? Is there any difference on creation date, modification date and
similar?

When I've found these files, I want to change their date manually


Any help?

Thursday 3 July 2008 20:58, text-dude wrote:

Hi,
>
Question: How to find all files between midnight and 08.00 am? How is
it? Is there any difference on creation date, modification date and
similar?
>
When I've found these files, I want to change their date manually

You can do something like (with GNU find)

find /basedir -type f -printf '%p %CH:%CM\n' |
awk '$NF>="00:00" && $NF<="08:00" && NF--'

to get a list of such files.

--
All the commands are tested with bash and GNU tools, so they may use
nonstandard features. I try to mention when something is nonstandard (if
I'm aware of that), but I may miss something. Corrections are welcome.

Saturday 5 July 2008 14:27, pk wrote:

for the test, but we're not interested in anymore). If we decrement the
value of NR (which represents the number of fields in the line), awk
thinks that the line has one field less. Since the overall value of the
expression is nonzero (all the tests have been successful, and NF is still
0, since it was at least 2 before), awk prints the (shortened) line.

Note that both solutions will fail if you have filenames with >= two
consecutive spaces in them.

--
All the commands are tested with bash and GNU tools, so they may use
nonstandard features. I try to mention when something is nonstandard (if
I'm aware of that), but I may miss something. Corrections are welcome.

Saturday 5 July 2008 14:08, text-dude wrote:

Why does it come up with such programming crap, when I wanted to see
the switches of /usr/xpg4/bin/find ?

Sorry, I misread your output. , it's programming stuff, you're correct. To
get find's man page, try

man 1 find

if that doesn't work, your system probably does not have a man page for find
installed. You may also try

find -h
find

to get an usage summary, but they are not guaranteed to work either.

Sunday 6 July 2008 18:49, James Kanze wrote:

>$ find /basedir -type f -printf '%p %CH:%CM\n' | awk '$NF>="00:00"
>&& $NF<="08:00" && NF--'
>find: bad option -printf
>find: [-H | -L] path-list predicate-list
>
All that means is that you are using Unix, and not some hacked
version; the Posix standard find doesn't have a -printf option.
And of course, you don't need it here anyway; awk is quite
capable of comparing any field, and -ls is standard for find.

My understanding is that -ls is NT standard. And, furthermore, with -ls
there is no way to print the file's access and change time. For those, you
have to use find -exec ls -l{u,c}.

--
All the commands are tested with bash and GNU tools, so they may use
nonstandard features. I try to mention when something is nonstandard (if
I'm aware of that), but I may miss something. Corrections are welcome.

Sunday 6 July 2008 19:34, James Kanze wrote:

Yes. Newlines are even more of a problem than spaces. Nul
characters will often cause problems as well

AFAIK, nul are illegal in filenames (unless you have a corrupted filesystem,
of course).

That's where GNU utilities, with their ability to output nul-delimited lists
of filenames can be safer than PSIX.

Monday 7 July 2008 10:44, text-dude wrote:

>sys: ~/ $ ls -l ./fig3011_SEQ.png
>-rw-r 1 sname32 sna 16628 Jun 1 16:54 ./
>fig3011_SEQ.png
>>
>That's probably due to localization issues. Try with
>>
>LC_ALL=en_US ls -l filename
>
No, doesn't work. What does your pc do? Does it enter the year when >
6 months or not?

No, I get this:

$ LC_ALL=en_US ls -l /bin

-rwxr-xr-x 1 root root 5404 2007-12-23 16:32 mountpoint
-rwxr-xr-x 1 root root 63144 2008-04-28 09:57 mv
-rwxr-xr-x 1 root root 112552 2008-07-02 10:29 nano
-rwxr-xr-x 1 root root 78976 2007-03-22 10:16 netstat


With C/PSIX locale I get this:

$ LC_ALL=C ls -l /bin

-rwxr-xr-x 1 root root 5404 Dec 23 2007 mountpoint
-rwxr-xr-x 1 root root 63144 Apr 28 09:57 mv
-rwxr-xr-x 1 root root 112552 Jul 2 10:29 nano
-rwxr-xr-x 1 root root 78976 Mar 22 2007 netstat


That's whay I thought it could be a localization issue. Make sure the en_US
locale is installed on your system doing "locale -a".

--
All the commands are tested with bash and GNU tools, so they may use
nonstandard features. I try to mention when something is nonstandard (if
I'm aware of that), but I may miss something. Corrections are welcome.

Monday 7 July 2008 13:14, James Kanze wrote:

The output in any locale except PSIX is implementation defined.
I'm getting the C/PSIX output in en_US.utf8 here, both under
Linux (Red Hat) and Solaris; on my Linux box at home (SuSE), I'm
pretty sure I've seen your output, and I think the locale I use
there is also en_US.utf8. AS I said, however, except in the
locale PSIX, the output is implementation defined, and may
vary.

course. But still, the P might be able to find a locale that produces an
output that can be processed. Mine was just an example, to make the point
that the output can vary depending on the locale used.

If you're writing shell scripts, one of the first things
you should do at the beginning is to set the locale to PSIX, so
you know what to expect.

Many people D want localized outputs, so they do NT set the locale to
PSIX. In this case, the P might be able to get a processable output by
using a non-PSIX locale.

--
All the commands are tested with bash and GNU tools, so they may use
nonstandard features. I try to mention when something is nonstandard (if
I'm aware of that), but I may miss something. Corrections are welcome.

Tuesday 8 July 2008 14:12, text-dude wrote:

>That's whay I thought it could be a localization issue. Make sure the
>en_US locale is installed on your system doing "locale -a".
>
You're right
>
It doesn't show up, so I guess it's not installed and ignores my
"en_US" setting, thus it just behaves in a "default" manner Neither
anything with "en" nor "us" is installed

Well, see what you have and try them one by one (if they are more than one,
of course :-)). It won't hurt anyway, and you might find one that works
(meaning "produce an easily parsable output").

Also, see if you have the "stat" utility on your system. If so, you can
perhaps do something like

find /basedir -type f -print -exec stat -c %x \{\} \; | awk '{getline nl;
dd=substr(nl,12,5); if ((dd>="00:00")&&(dd<="08:00")) print}'

to get a list similar to the one you got with my first solution,
assuming "stat" accepts the same options as GNU stat, and outputs the same
format (which of course cannot be assumed, and may not be true). If
your "stat" supports -c, the formats are %x, %y and %z to get access,
modification and change time resplectively.

--
All the commands are tested with bash and GNU tools, so they may use
nonstandard features. I try to mention when something is nonstandard (if
I'm aware of that), but I may miss something. Corrections are welcome.