I am using a macro to obtain data from a website and save to a print file using the print function on the specific website page.
In the print window i can select "print to pdf" but do not know how to format the output filename to reflect the current date.
The macro will be run every month to save a snapshot of the website's data.
I have tried several suggestions from the forums but haven't found a solution that works.
Filename required is of the form "yyyymmdd_account_summary.pdf"
Using Kantu as the macro recorder in firefox 68 on fedora 29.
i tried setting the print file name to
$(date +"%y%m%d")_account_summary.pdf
but this only created a file named
$(date +"%y%m%d")_account_summary.pdf
no variables were substituted.
obviously i am doing something simple wrong but cannot see it.
Expected resulting filename
20190731_account_summary.pdf
actual name that is created
$(date +"%y%m%d")_account_summary.pdf which is clearly wrong
We are not very familiar with Kantu but I suggest we do it in three steps.
Step 1. Let your macro runs periodically to a fixed file name (/tmp/my_temp_file.pdf).
Step 2. Write a script (bash or python) to monitor the file modify/overwrite timestamp and whenever it detects changes, copy the file (/tmp/my_temp_file.pdf) into "yyyymmdd_account_summary.pdf"
Step 3. Make a cronjob that invoke the script periodically.
Related
I just starting with DataStage, developing a project to process files I'm getting an strange error when the variable is mapped from a sequence job to parallel job, if I check the path in the error message the path exist and the file is there.. Any insight that can help to solve this problem. I'd really appreciate.. Below you can see with the pictures how the job is implemented and the error.
Thanks in Advance
The white space between your file path and the : in the error message are suspicious. Copy the file path directly from the log and paste into an editor that you can do character examination. You are likely having whitespace issues when looking to the path.
Please indicate what you are doing to the file path in the User Variables activity. The log appears to contain a valid Windows pathname, and reports "no such file or directory". Can you please validate that the file does indeed exist at that location? If it does not, then your ls | awk | tr pipeline or your sequence parameter TestFile_$DestinationPath may need some work.
I ran into the same situation where the file name being passed from the sequencer to the job looks to resolve correctly, but it gives the same error of file not found. Even though I copy the resolved name (taken from job log of the job) and open that path/file, it opens successfully. However, you do not see that DS is adding an extra "space" to the end of the resolved parameter value in the job. If you were to switch the input file stage from specific file to file pattern and just add * to the end of your file name, you will see that DS is trying to resolve the parameter value plus a space plus an *. For example, your sequencer is passing file name as "D:\abc.txt", but the job will see it as "D:\abc.txt *".
Actual job log entry of the job is:
ls: File or directory "D:\abc.txt *" is not found
The fix that worked for me is to do an Exchange of "0D" to "FF" in the User Variable stage. For some reason, DS was adding a carriage return in the User Variable stage. I wrote the file name to a text file to see what the value is being passed along the way and it always showed up as the correct value with no special characters added throughout my sequencer. By adding this Exchange in the User Variable expression, it worked for me as what you are expecting (passing the true file name value to the next job and able to read the file successfully). There is no need to actually switch to file pattern, but this was needed for debugging purposes to see the value actually being resolved in the job.
I have a script I created to help with converting a video then uploading it to our website. Our videos all have a standard format for their filename to help with setting them up correctly (day, month, year; i.e. 09OCT2013.m4v). They get filed into directories from year to month to day (i.e. 2013/oct/09OCT2013/09OCT2013.m4v). Right now, my script opens by asking for user input for the year then month then the actual file name for the folder. What I want to do is take the file that has already been created, drop it into the script, then have the script take it apart and put it in the appropriate file (i.e. drop the file 12JUN2012.m4v into the script and the script automatically puts it into 2012/jun/12JUN2012/). Is there any possible way to do this in terminal? Please let me know if any part of my question is unclear.
Assuming that you're using bash:
for file in "$#"
do
dd=${file:0:2}
mm=${file:2:3}
yy=${file:5:4}
mv "$file" "$yy/$mm/$file"
done
If the file needs to be moved further, or is supplied with more pathname, you can adjust the script, but the basic idea of splitting the last component of the file name up using the substring notation is good.
I would like to write WinSCP script to download a file that is placed onto the remote server every morning between 4-4:30am. Is there a way to do this with time-stamping?
I want to pseudocode:
get file.txt where timestap<1 hour from 4 am
First, I assume your file does not have fixed name (contrary to your question with fixed name file.txt). If not, please explain, why do you need timestamp-based solution.
Anyway, you can use a file mask with a time constraint:
get "*.txt>2014-07-19 4:00"
To dynamically inject today's date, use the %TIMESTAMP% syntax:
get "*.txt>%TIMESTAMP#yyyy-mm-ss% 4:00"
Simply, the above means, get all files created later than 4:00 today (the %TIMESTAMP#yyyy-mm-ss% resolves to today's date in format yyyy-mm-ss, as needed for the time constraint).
When passing the get on WinSCP command-line in a batch file (using /command switch, as opposite to using /script switch to specify a separate script file), you have to double the % to avoid the batch-file trying to interpret the %TIMESTAMP%:
winscp.com /command ... "get ""*.txt>%%TIMESTAMP#yyyy-mm-ss%% 4:00"""
Another solution is a static script that rely on a relative time: E.g. you know your script runs at 6am. So you let WinSCP download all files updated/created in the last 2 hours (6am – 4am):
get *.txt>2h
See also WinSCP article on downloading the most recent file.
I want to have last 500Mb worth of ipython input and output saved to a file
The saving described above should be able to get around instances when I have to kill ipython. For example, saving based on a timer
I want to have this file reloaded (not re-executed) at startup. The file then gets updated in a rolling fashion
How can I achieve this?
IPython already logs your input - it's stored in history.sqlite in your profile folder (run ipython locate profile to see where that is). To turn on output logging as well, edit ipython_config.py and search for 'db_log_output'. This captures output resulting from the displayhook (with the Out [n]: prompt), not printed output.
To look at history from a previous session, you can use %hist ~1/1-10 (lines 1-10 of the session before the current one). It also works with magic commands like %rerun, %recall and %save.
If you want it recorded to a text file, have a look at the %logstart magic.
Is there a LaTeX command that prints the "last modified" date of the actual document? Since LaTeX projects consist of more than one file this command ideally prints the date of the actual file, not that of the project.
pdfTeX provides the primitive \pdffilemoddate to query this information for files. (LuaTeX uses its own Lua functions for the same thing.) Since pdfTeX is used by default in all LaTeX distributions in the last few years (at least), there's no harm in using the new functionality unless you're dealing with very old production systems. Here's an example:
\documentclass{article}
\begin{document}
\def\parsedate #1:20#2#3#4#5#6#7#8\empty{20#2#3/#4#5/#6#7}
\def\moddate#1{\expandafter\parsedate\pdffilemoddate{#1}\empty}
this is the moddate: \moddate{\jobname.tex}
\end{document}
(Assuming the file has been modified since year 2000.)
The package filemod seems to do exactly what you need. To get the last modified date of the file you just include the package in the usual way:
\usepackage{filemod}
and the modification time of the current document is printed by:
\filemodprintdate{\jobname}
you can also print the modification time, and there are many options to format the output.
Unfortunately, TeX does not provide commands for such information; the only way to get such information is
by running a non-TeX script to create a TeX file before running LaTeX and including this file in your main LaTeX document somehow, or
by running the external script from TeX (which only works if the so-called write18 or shellescape feature is enabled; you'd have to consult the manual of your TeX implementation for this, and not have a stubborn sysadmin).
It is possible that extended TeXs do support file info commands (luaTeX perhaps?), but it's not part of TeX proper.
If you are using an automated build system, you could ask it to generate a file (perhaps named today.sty) which depends on all the source files.
In make that might look like:
today.sty: $LATEX_SRCS
echo "\date{" > $#
date +D >> $#
echo "}" >> $#
and \usepackage{today.sty}.
The will use the date of the first build after a file changes, and won't update until either you delete today.sty or alter another source file.
thank dmckee
LATEX_SRCS = test.tex
define moddate
date +%Y%m%d%H%M%S
endef
today.sty: $(LATEX_SRCS)
#echo "\def\moddate{"$(shell $(moddate))"}"> $#
There is the getfiledate LaTeX package (it was part of my LaTeX distribution by default). It seems to be designed to automatically output a paragraph like:
The date of last modification of file misc-test1.tex was 2009-10-11 21:45:50.
with a bit of ability to tweak the output. You can definitely get just the date. However, I couldn't figure out how to get rid of newlines around the date and how to change the date format. To be honest I think the authors implemented it exactly for the single purpose they needed it, and it is rather cumbersome for general use.