While executing the tmpwatch to clean the tmp directory in Unix, we are getting the error:
error: bad time argument filename.
But the same command working in another server. Please suggest ways to resolve the issue.
/etc/cron.daily/tmpwatch is a very picky file that will cry when the syntax is not just right.
Take a look at your exclusion list.
If you have an absolute file name or directory name:
-x /tmp/filename
If you have a wildcard:
-X '/tmp/file*'
Not having the correct switch or/and not having the single quotes around the path with the wildcard in it will produce a bad time argument error.
Related
when i run a command on windows 10 command line that requires a path as one of its params, it works if the path is NOT inside a quotation, but if a path has a space in it, i need to wrap it inside quotes so that it treats as one single path, but then it complains that the file in that path does not exists.
For example:
C:/PROJECTS/desktopfiles/public/libs/cpdf/win64/cpdf.exe C:/Users/john/Documents/cat.pdf C:/Users/john/Documents/my_dog.pdf -o C:/Users/john/Documents/cat_dog_Merged.pdf
The above works,
the below doesn't (because there is a space in my dog.pdf)
C:/PROJECTS/desktopfiles/public/libs/cpdf/win64/cpdf.exe C:/Users/john/Documents/cat.pdf C:/Users/john/Documents/my dog.pdf -o C:/Users/john/Documents/cat_dog_Merged.pdf
You could try to replace spaces with a question mark. The question mark is a wildcard to match "any single character", which would be a space in your case. Like this: my?dog.pdf. Just make sure that there is no other file matching this pattern. But the system should give you some error message then (which might or might not point to the root of the problem).
Another solution that comes to my mind is a batch file that renames the files in question automatically (replacing spaces with underscores) and renames them back after the pdf merge.
In Windows 10 (cmd) I'm trying to copy a file from a subfolder containing a space character in its name.
First I tried to use quotation marks:
FROM jfloff/alpine-python:2.7
COPY "Folder 1/File.txt" "Dir 1"
Error message:
failed to process "\"Folder": unexpected end of statement while looking for matching double-quote
"JSON" format (skipped the first line):
COPY ["Folder 1/File.txt" "Dir 1"]
Error message:
failed to process "[\"Folder": unexpected end of statement while looking for matching double-quote
Trying to escape with a single backslash:
COPY "Folder\ 1/File.txt" "Dir\ 1"
Error message:
failed to process "\"Folder\\": unexpected end of statement while looking for matching double-quote
Trying to escape with a double backslash:
COPY "Folder\\ 1/File.txt" "Dir\\ 1"
Error message:
failed to process "\"Folder\\\\": unexpected end of statement while looking for matching double-quote
Also tried a suggestion to use %20 instead of space:
COPY ["Folder%201/File.txt" "Dir%201"]
Error message:
COPY failed: no source File
Escape character replacement:
# escape=`
COPY "Folder` 1/File.txt" "Dir 1"
Error message:
failed to process "\"Folder`": unexpected end of statement while looking for matching double-quote
The same, but without quotes:
#escape=`
COPY Folder` 1/File.txt Dir` 1
Error message:
COPY failed: stat /var/lib/docker/tmp/docker-builder082039614/Folder: no such file or directory
Method with packing / unpacking using a tar archive (I'm not happy with that idea).
It should be possible, shouldn't it?
Maybe you can use ARG to help you, like this:
Dockerfile:
FROM jfloff/alpine-python:2.7
ARG src="Folder 1/File.txt"
ARG target="Dir 1/"
COPY ${src} ${target}
BTW, a / has to be add at the end of Dir 1 if you treat really want to treat it as a folder.
And, JSON format is also ok, just you miss ,, it should be:
FROM jfloff/alpine-python:2.7
COPY ["Folder 1/File.txt", "Dir 1/"]
Update for your comments:
In official guide, it said:
When copying files or directories that contain special characters (such as [ and ]), you need to escape those paths following the Golang rules to prevent them from being treated as a matching pattern.
So, for your case, it should be:
FROM jfloff/alpine-python:2.7
ARG src="[[]Folder 1]/__SLIM_TEMPLATE.mm"
ARG target="[Folder 1]/"
COPY ${src} ${target}
Or:
FROM jfloff/alpine-python:2.7
COPY ["[[]Folder 1]/__SLIM_TEMPLATE.mm", "[Folder 1]/"]
agree it's annoying to get files from docker that have special characters,
had similar experience and after hours of try and errors, I came up with this simple solution that I now use since then.
tar/zip the files and then "docker cp" them easily without having to worry about dozens of []'"..
tar files in your container machine:
#zipped
tar czf myfiles.tar.gz file1.txt dir24 file_xyz
#or unzipped
tar -cvf myfiles.tar file1.txt dir24 file_xyz
Then copy them to local directories in your windows machine.
open cmd in windows
run
# docker cp ABCD_CONTAINER_NAME:PATH/myfiles.tar.gz d:/TARGETDIR/
check if files have been transferred in d:/TARGETDIR/
The solution is the follow:
Docker has updated it's COPY command. So you can use brackets and your filenames can have whitespaces. Read more here (official docs)
I want to create the following variable in Bash:
PATHTOMYDIR=/fshare/users/myusername/
(basically, a variable with a string inside: the path to my directory, where I have my data, that later on can be included in some scripts to generate folders inside that directory, for example).
The concrete problem is: when I typed that line of code I got the following error message:
-bash: /fshare/users/myusername: Is a directory
Hence, I wanted to ask: does Bash not allow a variable to contain the name of a path? I thought it was possible, so I assume I am missing something else here. I googled the error message but I did not find any post at any forum with this case.
I had a space between the "=" and the first "/" of the path.
This makes an error:
PATHTOMYDIR= /fshare/users/myusername/
This is correct:
PATHTOMYDIR=/fshare/users/myusername/
It seems that space makes the difference. Thank you #AIG and #Jason !
EDIT: #Jason pointed out that is good practice to use commas, so a more correct form would be:
PATHTOMYDIR="/fshare/users/myusername/"
I'm using xsltproc on Windows as per this guide
When I run xsltproc with relative paths, i.e.:
xsltproc -o "..\output.html" "c:\templates\out.xsl" "c:\data\input.xml"
everything is ok.
But when I run it with absolute paths, it fails, e.g.:
xsltproc -o "c:\output.html" "c:\templates\out.xsl" "c:\data\input.xml"
I/O error : Invalid argument
I/O error : Invalid argument
tried both with forward and backward slashes as path separators, with the same result (the problem is only for the -o argument)
How does xsltproc expects a Windows absolute path to be encoded?
For me it was an issue with the output file path; even though it has been double-quoted it still gave the error. As soon as I have removed the folder containing spaces it has worked. Oddly, the %I file fed in was in the same space-containing folder and I did not need to modify that one.
It seems that xsltproc is not aware of drive letters ("C:\path\to\output\output.html"). The spaces and backslashes are no problem. If I remove the drive letter from the "output" ("\path\to\output\output.html") everything works fine.
The problem with this "solution" is that input and output must share the drive letter.
Jens
I have to ls command to get the details of certain types of files. The file name has a specific format. The first two words followed by the date on which the file was generated
e.g.:
Report_execution_032916.pdf
Report_execution_033016.pdf
Word summary can also come in place of report.
e.g.:
Summary_execution_032916.pdf
Hence in my shell script I put these line of codes
DATE=`date +%m%d%y`
Model=Report
file=`ls ${Model}_execution_*${DATE}_*.pdf`
But the value of Model always gets resolved to 'REPORT' and hence I get:
ls: cannot access REPORT_execution_*032916_*.pdf: No such file or directory
I am stuck at how the resolution of Model is happening here.
I can't reproduce the exact code here. Hence I have changed some variable names. Initially I had used the variable name type instead of Model. But Model is the on which I use in my actual code
You've changed your script to use Model=Report and ${Model} and you've said you have typeset -u Model in your script. The -u option to the typeset command (instead of declare — they're synonyms) means "convert the strings assigned to all upper-case".
-u When the variable is assigned a value, all lower-case characters are converted to upper-case. The lower-case attribute is disabled.
That explains the upper-case REPORT in the variable expansion. You can demonstrate by writing:
Model=Report
echo "Model=[${Model}]"
It would echo Model=[REPORT] because of the typeset -u Model.
Don't use the -u option if you don't want it.
You should probably fix your glob expression too:
file=$(ls ${Model}_execution_*${DATE}*.pdf)
Using $(…) instead of backticks is generally a good idea.
And, as a general point, learn how to Debug a Bash Script and always provide an MCVE (How to create a Minimal, Complete, and Verifiable Example?) so that we can see what your problem is more easily.
Some things to look at:
type is usually a reserved word, though it won't break your script, I suggest you to change that variable name to something else.
You are missing an $ before {DATE}, and you have an extra _ after it. If the date is the last part of the name, then there's no point in having an * at the end either. The file definition should be:
file=`ls ${type}_execution_*${DATE}.pdf`
Try debugging your code by parts: instead of doing an ls, do an echo of each variable, see what comes out, and trace the problem back to its origin.
As #DevSolar pointed out you may have problems parsing the output of ls.
As a workaround
ls | grep `date +%m%d%y` | grep "_execution_" | grep -E 'Report|Summary'
filters the ls output afterwards.
touch 'Summary_execution_032916.pdf'
DATE=`date +%m%d%y`
Model=Summary
file=`ls ${Model}_execution_*${DATE}*.pdf`
worked just fine on
GNU bash, version 4.3.11(1)-release (x86_64-pc-linux-gnu)
Part of question:
But the value of Model always gets resolved to 'REPORT' and hence I get:
This is due to the fact that in your script you have exported Model=Report
Part of question:
ls: cannot access REPORT_execution_*032916_*.pdf: No such file or directory
No such file our directory issue is due to the additional "_" and additional "*"s that you have put in your 3rd line.
Remove it and the error will be gone. Though, Model will still resolve to Report
Original 3rd line :
file=`ls ${Model}_execution_*${DATE}_*.pdf`
Change it to
file=`ls ${Model}_execution_${DATE}.pdf`
Above change will resolve the could not found issue.
Part of question
I am stuck at how the resolution of Model is happening here.
I am not sure what you are trying to achieve, but if you are trying to populate the file parameter with file name with anything_exection_someDate.pdf, then you can write your script as
DATE=`date +%m%d%y`
file=`ls *_execution_${DATE}.pdf`
If you echo the value of file you will get
Report_execution_032916.pdf Summary_execution_032916.pdf
as the answer
There were some other scripts which were invoked before the control reaches the line of codes which I mentioned in the question. In one such script there is a code
typeset -u Model
This sets the value of the variable model always to uppercase which was the reason this error was thrown
ls: cannot access REPORT_execution_032916_.pdf: No such file or directory
I am sorry that
i couldn't provide a minimal,complete and verifiable code