does anybody have idea why some windows XP installation would not evaluate path with double backslash in them?
Error is found on some XP (same build, patches, unknown more details). In most everything works, on some PCs following doesn't work:
Querying path (registry or folder) with functions like RegEnumKeyEx, fopen fails if path contains two backslashes, for example C:\\test\hello.txt.
strPath = "\SOFTWARE\Microsoft\Windows\Currentversion\run" // works
strPath = "\SOFTWARE\Microsoft\Windows\Currentversion\\run" // doesn't work
Is there some policy option or setting which can affect it?
Any help welcome,
RM
Why don't you simply modify the path to only have a single \ before using it?
Possibly completely unrelated, but in C/C++ (and other languages too) -
"c:\\\\test\hello.txt" is okay, but "c:\test\hello.txt" is not (because \t is parsed as a tab character, so you get a name that doesn't really exist).
Is there a chance the failure happens when the two backslashes don't exist, and things work when they do?
Related
My work place has an extensive script library that uses plenty of system commands to make directories. Previously, all this work was done on Linux so everything is hardcoded with forwarded slashes "/", but we now want to make it windows compatible.
At the moment, trying to make a directory with system('mkdir ../dir') throws an error because Windows command line uses back slashes "\" for making directories.
Is there an easy way to tell windows to treat the hardcoded forward slashes as back slashes?
My only thought right now is to do a if(ispc) command and set a variable to "\" or "/" accordingly, but I want to know if there are alternatives.
Thanks!
There is probably a way to automate the procedure, but I'd recommend a one-time general solution. Unless we're talking about a thousand cases, you should be able to do it by hand.
The filesep function is the dedicated function for this purpose, it will always return the correct file seperator for every OS. So just go to your files and replace all \ with ' filesep ' (probaly some [...] are required as well).
The symbol is this one:
It crops up at the end of folder names sometimes on our filesystem. The people who put the folder there swear that they couldn't see it. I think it might be being produced by one of our internal asset building tools, perhaps in response to something copied in from a Google docs spreadsheet?
Sorry that's so vague...
It looks like the culprit could be Windows CHKDSK (analogous to fsck) …
https://github.com/dw/scratch/blob/master/ntfs-3g-chkdsk-unicode-fix.py →
# … Windows
# CHKDSK, which will immediately replace all the invalid characters with
# Unicode ordinals in the private use plane.
This symbol is used by OS X if you add a trailing space to a folder name on a FAT file system.
Why? Because it is forbidden to have trailing spaces in folder names on Windows. As OS X allows trailing spaces in general, it somewhat extends this behavior to FAT drives. The private use unicode character is used as a means to keep the file system sane at the same time.
While you're on the Mac, you barely see the additional character as it is rendered as space there. Only after moving the drive to Windows or Linux, the weird unicode character shows up as unprintable.
This is the unicode character U+F028 which falls in the private use area of U+E000–U+F8FF. This means it's use is application specific. You are probably right that some tool produces this character and fails to remove/replace that character when copying. Wikipedia lists some vendor usage examples but I doubt that this list will help much.
To find the cause of the problem, I would first try asking the users who created the folders about which operating systems they use and which applications they copied the text from. If you think one of your build tool is the cause, you could try to search for that character in all log files of those tools and any databases that the tools use.
As for the actual question in the title, this character does not have a defined symbol. Some applications show a default symbol while other application may just ignore it and show nothing.
When using the following script:
Run, *verb TargetFile
...Is there any way to make it work for verbs that contain a space? Simply writing it out as normal, the program interprets anything after the space as part of the target file. I've tried passing the verb as a variable, using double quotes in various spaces, but nothing seems to work.
Thanks.
Even though you said you had tried double quotes, here is an example that works with run and contains spaces:
Run "C:\Program Files\Internet Explorer\iexplore.exe" http://www.google.com
The most common use for a space in ahk is %A_Space%.
You could also try backtick s ('s btw I can't use backticks here, but they are below the ~ on a US keyboard). The use of 's is rare but has been shown to work in concatenation.
I made Localizable.string files and compiled my project (my source code uses NSLocalizedString macro function) but my project doesn't compile because of the Localizable.string file. If I comment all the lines in the Localizable.string file, my project compiles successfully.
As result, the problem is related with the Localizable.string files. I searched about it on Google, I found that UTF-8 files (Localizable.string) has changed to UTF-16. And though I tried this... this way didn't work, too.
===============================================================
My Localizable.string file contains:
"LOCAL_APP_GRADE" = "Basic"
"LOCAL_APP_LAST_UPDATED_DATE" =
"2011/04/20"
"LOCAL_MAIN_MENU_TITLE" = "Main Menu"
In my source code:
NSLocalizedString( #"LOCAL_MAIN_MENU_TITLE", #"" );
Error message:
Copy .strings file Error Validation failed: The data couldn't be read because it has been corrupted.
I'm assuming Xcode 4 here. Double check what it shows for the encoding on each of the Localization.string files in the file inspector. When I was having that error it was due to one of the files being read as Mac Roman instead of UTF-16. Once I changed the encoding the warning went away. What was driving me nuts at first was that the warning was only happening in Xcode 4. Xcode 3 did not give it.
You also have an issue with the formatting of your .string file. All of the lines should end in a semicolon.
"LOCAL_APP_GRADE" = "Basic";
"LOCAL_APP_LAST_UPDATED_DATE" = "2011/04/20";
"LOCAL_MAIN_MENU_TITLE" = "Main Menu";
I don't think this is the cause of the warning though. At least I've never seen a warning for it. It usually only manifests itself at runtime when LOCAL_MAIN_MENU_TITLE shows up in app instead of Main Menu. It would be nice if the build process did check for semicolons though. It's easy to miss adding one when editing the files.
Per Apple:
If you run into problems during testing and find that the functions
and macros for retrieving strings are always returning the same key
(as opposed to the translated value), run the /usr/bin/plutil tool on
your strings file. A strings file is essentially a property-list file
formatted in a special way. Running plutil with the -lint option can
uncover hidden characters or other errors that are preventing strings
from being retrieved correctly.
Fire up a console window, go into your project folder, and do:
/usr/bin/plutil -lint ja.lproj/Localizable.strings
(obviously replace the correct language folder name). This will tell you exactly where the problem is!
All of the lines in .strings file should end with a semicolon. It worked for me.
I had the same issue today after importing the localisations from Apple Notes and the cause was really subtle. The standard double quotes had been swapped with slanting double quotes.
Slanting double quote: ”
Standard double quote: "
I've been struggling with this same error, and ended up having a couple similar issues, but with different details. First off, even though it appears that Xcode's internal "builtin-copyStrings" tool should be able to handle either little-endian or big-endian UTF-16 files, it really only handles big endian. My theory is it's running some extra validation step (perhaps using the plutil command line utility) that didn't used to happen in Xcode 3, and that tool barfs on anything but big-endian UTF-16. Not entirely sure though.
The second trick is that you need to make sure your strings files are saved with no BOM (Byte Order Marker). I did some editing of my .strings files in BBEdit, which ended up saving a BOM to the file, and that also appears to make Xcode 4 have a conniption fit. Xcode itself doesn't appear to have any way to remove the BOM from the file, so this has to be done in a text editor such as BBEdit or TextWrangler which can do that for you.
With Xcode 10.1, one missing semicolon stops compilation with this error:
Localizable.strings: read failed: Couldn't parse property list because
the input data was in an invalid format
BTW, you can find out if the error is general to your file (an encoding issue) or specific to one or more lines by temporarily removing most of the file content. You can then locate the problem by incrementally adding content back in until the error returns.
Perhaps you have something like:
"Bla"="bla";;
Note the duplicate ; symbol. If you have that, it will compile properly but will fail in run time.
Related to this - take care when manually merging strings into Localizable.strings - I managed to copy/paste BOTH strings from a NSLocalizedString() macro, so that the Localizable.strings entry was in this form:
"KEY" = "STRING", #"COMMENT STRING COPIED ACROSS ALSO, IN ERROR";
The bit ,#"xxx" on building caused me to get the error:
Read failed: The data couldn't be read because it isn't in the correct
format.
In this case doing a quick search on #" helped identify the places I'd done this.
I had this problem. My fix? Add a newline at the top of the file. Bizarre but it got it working for me.
So instead of at the top of my file having this:
/* comment */
"LOCAL_APP_GRADE" = "Basic"
I had to do:
[newline]
/* comment */
"LOCAL_APP_GRADE" = "Basic"
(Can't get the formatting right - don't type 'newline', just hit return!)
Looks like this is an standard message for error reading the strings file.
In my case it was a (json force of habit) colon instead of equal sign:
"key1" = "String1";
"key2" : "String2";
"key3" = "String3";
Changed it to = and everything worked fine.
My problem was, that I've forgotten ; in one of the lines
Make sure that you have declared string in following format:
"YOUR_STRING_LABEL" = "Your message";
Note: Don't forget Quotation Marks ("), Equals Sign (=) and Semicolon (;) at end.
This may be because the translation file format is wrong. You can download a mac software called Localizable.
This is the download link: https://apps.apple.com/cn/app/localizable-翻译文件工具/id1268616588?mt=12
You only need to drag Localizable.strings file to the software. and it willtell you which line in the file may have a problem.
It is useful .It saved me a lot of time. Now I share it with you, I hope it will be helpful to you.
My Localizable.strings file has somehow been corrupted and I don't know how to restore it.
If I open it as a Plain Text File it starts with weird characters that I can't copy here.
If I leave the file be the app builds. If I make any changes either the values aren't interpreted properly or I get an error at compile time.
Localizable.strings: Conversion of string failed. The string is empty.
Command /Developer/Library/Xcode/Plug-ins/CoreBuildTasks.xcplugin/Contents/Resources/copystrings failed with exit code 1
I suspect this is an encoding problem but I don't know how it happened (maybe SVN is to blame?) nor how to solve it. Any tips will be much more appreciated.
I have issues with the same file that sound very similar to your own. What happens for me is that Xcode doesn't know the correct file formating. I often get this when rearranging the project and I remove and re-add this file to the Xcode project. When I re-add the file, its encoding gets set to something like Western Roman which can't seem to render anything other than ASCII.
Here's what I do to fix the problem:
In Xcode select the Localizable.stings file in the Groups&Files panel.
Do a Get Info on that file.
On the info panel select the General tab.
In that tab go to the File Encoding and change its value.
The last step is where the trick lies as you now have to guess the right encoding. I find that for most European languages that "Unicode (UTF-8)" works. And for Asian languages I find that "Unicode (UTF-16/32)" are the ones to try.
I just had that error because I forgot a semicolon. Took me a while to figure it out. Seems like a really ambiguous compiler error but the fix was simple.
Make sure in File-Get Info, that UTF-16 is selected. If it's set to none or UTF-8 as encoding then you need to change it. If your characters have spaces between them then you choose to "re-interpret" the file as UTF-16. If there are weird characters in the file, then you need to remove them.
Execpt the UTF-8 problem, sometimes you still have to check the content in case if there are some syntax problems.
Use the following Regular Expression to verify your text line by line, if there's any line not matched, there must be a problem.
"(.+?)"="(.+?)";
You can use the plutil command line tool. Without options or with the -lint option, it checks the syntax of the file given as argument. It will tell you more precisely where the error is.
This happens to me when there is a missing quote or something not right with the file. MOst commonly, since my language files are done by another team member, he tends to forget a quote or something. Usually XCode shows an error on that line, sometimes it does'nt and just throws "Corrupted data" error.
Double check if all your strings are properly closed in quotes
Open the file in Xcode.
Right click it in Project Navigator.
Select Open as -> ASCII Property List