I'd like to script p4 a little. Unfortunately, some of the filenames that we're tracking have "#" in the filename.
The filenames are in the form a#b.xml. If I try to do something like p4 sync a\#b.xml on a mac (or p4 sync a#b.xml on windows) it gives the error:
Invalid changelist/client/label/date '#b.xml'
Is there another way to escape it that perforce will recognize?
Yes. Use the ASCII expression of the character's hexadecimal value.
p4 sync a%40b.xml
See this article: Limitations on characters in filenames and entities.
Related
I'm having an issue figuring out how to ignore signs and variables in a single quote string statement.
I am attempting to update a table with the new text with structure such as:
update xxx
set xxx =
'Our Ref. $BOOKING_NO$
.......
Kind regards'
If your $ chars are being interpreted, it isn't by Oracle ($ isn't special in Oracle anyway, and between single-quotes everything is a string), but rather by your client program or maybe shell script. If, for example, you are running this in SQL*Plus from a Unix-based shell script, you will need to use the appropriate means required by the shell you use to prevent the shell from interpreting $ and ' characters.
I cant think of an OS (Linux, Windows, Unix) where this would cause an issue but maybe someone here can tell me if this approach is undesirable.
I would like to use a base64 encoded string as a filename. Something like gH9JZDP3+UEXeZz3+ng7Lw==. Is this likely to cause issues anywhere?
Edit: I will likely keep this to a max of 24 characters
Edit: It looks like I have a character that will cause issues. My function that generated my string is providing stings like: J2db3/pULejEdNiB+wZRow==
You will notice that this has a / which is going to cause issues.
According to this site the / is a valid base64 character so I will not be able to use a base64 encoded string for a filename.
No. You can not use a base64 encoded string for a filename. This is because the / character is valid for base64 strings which will cause issues with file systems.
https://base64.guru/learn/base64-characters
Alternatives:
You could use base64 and then replace unwanted characters but a better option would be to hex encode your original string using a function like bin2hex().
The official RFC 4648 states:
An alternative alphabet has been suggested that would use "~" as the 63rd character. Since the "~" character has special meaning in some file system environments, the encoding described in this section is recommended instead. The remaining unreserved URI character is ".", but some file system environments do not permit multiple "." in a filename, thus making the "." character unattractive as well.
I also found on the serverfault stackexchange I found this:
There is no such thing as a "Unix" filesystem. Nor a "Windows" filesystem come to that. Do you mean NTFS, FAT16, FAT32, ext2, ext3, ext4, etc. Each have their own limitations on valid characters in names.
Also, your question title and question refer to two totally different concepts? Do you want to know about the subset of legal characters, or do you want to know what wildcard characters can be used in both systems?
http://en.wikipedia.org/wiki/Ext3 states "all bytes except NULL and '/'" are allowed in filenames.
http://msdn.microsoft.com/en-us/library/aa365247(VS.85).aspx describes the generic case for valid filenames "regardless of the filesystem". In particular, the following characters are reserved < > : " / \ | ? *
Windows also places restrictions on not using device names for files: CON, PRN, AUX, NUL, COM1, COM2, COM3, etc.
Most commands in Windows and Unix based operating systems accept * as a wildcard. Windows accepts % as a single char wildcards, whereas shells for Unix systems use ? as single char wildcard.
And this other one:
Base64 only contains A–Z, a–z, 0–9, +, / and =. So the list of characters not to be used is: all possible characters minus the ones mentioned above.
For special purposes . and _ are possible, too.
Which means that instead of the standard / base64 character, you should use _ or .; both on UNIX and Windows.
Many programming languages allow you to replace all / with _ or ., as it's only a single character and can be accomplished with a simple loop.
In Windows, you should be fine as long if you conform to the naming conventions of Windows:
https://learn.microsoft.com/en-us/windows/win32/fileio/naming-a-file#naming-conventions.
As far a I know, any base64 encoded string does not contain any of the reserves characters.
The thing that is probably going to be a problem is the lengte of the file name.
On my Windows 10 PC LabVIEW 2017 is installed. A file I created in LabVIEW 2016 at my Uni will not be opened. When I doubleklick, LabVIEW starts normally, but only as if I had opened it without any file. If I start LabVIEW normally and try to open the file out of the program, nothing will happen, not even an error will occur. Why is this?
Note: Right now I am using LabVIEW 2017 in Evaluation-Mode.
Technically, I think the answer is that ASCII 26 is not a valid character for a Windows path or filename, per the following: https://msdn.microsoft.com/en-us/library/windows/desktop/aa365247(v=vs.85).aspx
Use any character in the current code page for a name, including
Unicode characters and characters in the extended character set
(128–255), except for the following:
The following reserved characters:
< (less than)
> (greater than)
: (colon)
" (double quote)
/ (forward slash)
\ (backslash)
| (vertical bar or pipe)
? (question mark)
* (asterisk)
Integer value zero, sometimes referred to as the ASCII NUL character.
Characters whose integer representations are in the range from 1
through 31, except for alternate data streams where these characters
are allowed. For more information about file streams, see File
Streams.
Any other character that the target file system does not allow.
(Emphasis mine.)
I found the reason... The file was saved in a subfolder of a folder which name contained a right arrow (→) which is not supported by LabVIEW obviousely...
We are using crontab to schedule jobs and it was not picking the files for processing that have [ or ] or ¿ . Is there any limitation in giving file name or these characters means something in UNIX? Is there any other variables like these we shouldnt use in file name?? Thanks in advance.
Following are general rules for both Linux, and Unix (including *BSD) like systems:
All file names are case sensitive. So filename vivek.txt Vivek.txt VIVEK.txt all are three different files.
You can use upper and lowercase letters, numbers, "." (dot), and "_" (underscore) symbols.
You can use other special characters such as blank space, but they are hard to use and it is better to avoid them.
In short, filenames may contain any character except / (root directory), which is reserved as the separator between files and directories in a pathname. You cannot use the null character.
No need to use . (dot) in a filename. Some time dot improves readability of filenames.
And you can use dot based filename extension to identify file. For example:
.sh = Shell file
.tar.gz = Compressed archive
Most modern Linux and UNIX limit filename to 255 characters (255 bytes). However, some older version of UNIX system limits filenames to 14 characters only.
A filename must be unique inside its directory. For example, inside /home/vivek directory you cannot create a demo.txt file and demo.txt directory name. However, other directory may have files with the same names. For example, you can create demo.txt directory in /tmp.
Linux / UNIX: Reserved Characters And Words
Avoid using the following characters from appearing in file names:
/
>
<
|
:
&
Please note that Linux and UNIX allows white spaces, <, >, |, \, :, (, ), &, ;, as well as wildcards such as ? and *, to be quoted or escaped using \ symbol.
It will be good if you can avoid white spaces in your filename. It will make your scripting a lot more easier.
I got the answer from this link. I am just pasting it here so that this info will be available even if that website goes down.
The only characters that are actually illegal in *nix filenames are / (reserved as the directory separator) and NUL (because it's the C string terminator). Everything else is fair game, although various utilities may fail on certain characters - typically characters that have special meaning to the shell. These will need quoting or escaping to be handled correctly.
in my MSBuild every text that has this pattern $(SomeText) is considered as property reference. I have an MSBuild Custom Task that writes content to some text file and the text that needs to be written is $(SomeText) thus MSBuild does not let this pass through because it is considered as properry reference.
Any workaround.
Many thanks,
Idriss
MSBuild uses same escaping as in URL. Use %24 instead of $
Here and here is a full list of ASCII character codes