 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I think I've got things sorted out, including the naming. Well, mostly.
I got a batch file that puts GMT into a variable to use, so the file
is named "clouds_4096 %date% %_gmt%.jpg" ...but the internals of the
batch file only fix the time, not the date. Will see if it's smart
enough to account for that or not. Still might have to go in and add
checking for day/month/year rollover spots. wget doesn't like any
colons used in the filename, even when added from a variable, so I had
to trim the time to hhmm instead of hh:mm. Luckily that's what I was
already doing...
--
Tim Cook
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 15/11/2010 11:04 AM, Tim Cook wrote:
> wget doesn't like any colons used in the
> filename, even when added from a variable, so I had to trim the time to
> hhmm instead of hh:mm. Luckily that's what I was already doing...
As an aside, I think it's a bad idea to put colons in filenames anyway.
(And yes, variables are expended by the shell; wget can't tell the
difference between stuff you typed in and stuff the shell expended from
an environment variable. So if it doesn't like it when you type it, it
won't like it when the shell types it.)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 11/15/2010 6:04 AM, Tim Cook wrote:
> I think I've got things sorted out, including the naming. Well, mostly.
> I got a batch file that puts GMT into a variable to use, so the file is
> named "clouds_4096 %date% %_gmt%.jpg" ...but the internals of the batch
> file only fix the time, not the date. Will see if it's smart enough to
> account for that or not. Still might have to go in and add checking for
> day/month/year rollover spots. wget doesn't like any colons used in the
> filename, even when added from a variable, so I had to trim the time to
> hhmm instead of hh:mm. Luckily that's what I was already doing...
>
> --
> Tim Cook
my standard file timestamp
name_2010-11-15_13-04-23
good luck getting it all working
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Tim Cook wrote:
> wget doesn't like any colons used in the filename,
Nobody under Windows likes colons in the file name for the same reason they
don't like slashes in the file name. They're part of the syntax for
navigating files. "hello.txt:xyz" is a different part of the "hello.txt" file.
--
Darren New, San Diego CA, USA (PST)
Serving Suggestion:
"Don't serve this any more. It's awful."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 2010-11-15 10:04, Tom Austin wrote:
> good luck getting it all working
Interestingly, it
a) hasn't been executing properly on this machine since I plugged it
into task manager, will see if adding a 'run in path' option will fix
that, since it /does/ work if I go to the directory and run the batch
file manually
b) flags 2010-11-15 21:46 CST as 2010-11-15 27:46 GMT rather than
2010-11-16 03:46 GMT. heh. oh well, six of one, half a dozen of the
other...
--
Tim Cook
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 16/11/2010 03:47 AM, Tim Cook wrote:
> On 2010-11-15 10:04, Tom Austin wrote:
>> good luck getting it all working
>
> Interestingly, it
> a) hasn't been executing properly on this machine since I plugged it
> into task manager, will see if adding a 'run in path' option will fix
> that, since it /does/ work if I go to the directory and run the batch
> file manually
In general, for anything related to Task Scheduler, you want to be using
absolute paths *everywhere*, since there's no telling what the current
path will be. Sometimes you also need to write explicit paths to
executables, since the search path may be different than usual.
Basically, TS runs things under a completely different user account. You
need to take account of everything that could possibly be different.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
It turns out that the reason task scheduler was bombing with an "invalid
directory" was because I had in its "Start in directory" field
"C:\Public [G]\5\5\1\global\" when it wanted C:\Public [G]\5\5\1\globla\
...without quotes. (Where the field for the thing *to* run did want
quotes for directories with spaces.) Works just fine, now.
-_-
How about a little consistency!?
--
Tim Cook
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 17/11/2010 08:43 AM, Tim Cook wrote:
> How about a little consistency!?
Or even documentation...
As I say, what I tend to do is put absolute paths for *everything* in a
script file, and run that. That way, I can run multiple scripts without
having to edit the Task Scheduler properties. (Plus, since it runs on a
server, I'd have to sign and date the log in blood if I changed a
configuration setting...)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New wrote:
> Tim Cook wrote:
>> Hmm. Looks like it's working, but it's saving the files with default
>> filenames...clouds_4096.jpg.1 and clouds_4096.jpg.2 and so forth, but
>> I'd like the names to be better. Hmmm.
>
> You're going to need to write a .bat file or something to pluck the
> date/time into an environment variable and use it in a command to either
> rename the file or pass it on the -O argument.
>
> date +%s
>
> should give you seconds-since-midnight as a date, if you're comfortable
> with unixy scripting.
"date +%s" won't work on Windows unless you got date.exe from ported GNU
coreutils.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nicolas Alvarez wrote:
> "date +%s" won't work on Windows unless you got date.exe from ported GNU
> coreutils.
I figured he has wget.... ;-)
--
Darren New, San Diego CA, USA (PST)
Serving Suggestion:
"Don't serve this any more. It's awful."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
