The HSQLDB documentation says something to the effect of:
Special care may be needed w.r.t. file path specifications containing whitespace, mixed-case, special characters and/or reserved file names. Please read your OS file system documentation.
However, they provide ZERO documentation or examples on the syntax for actually using file names with reserved characters or spaces. When I use a file name with a space in it, HSQLDB appears to simply hang my entire application.
I've tried escaping with URL syntax ("%20") which does not work because HSQLDB interprets that literally. I've tried surrounding various portions of the JDBC URL with single and double quotes. Most result in a failure to access the database error. At least they don't simply hang.
Does anyone know the proper way to reference an embedded HSQLDB file when the file path has spaces?
When I use a file name with a space in it, HSQLDB appears to simply hang my entire application.
For what it's worth, my Windows (Vista) test box has no problems with spaces in the database path or the database name
String connStr = "jdbc:hsqldb:file:C:/Users/Public/test/HSQLDB test/my db";
try (Connection con = DriverManager.getConnection(connStr, "sa", "")) {
results in this
Tested using hsqldb-2.3.1.
Related
I am trying to use wget -m <address> to download the contents of an FTP server. A lot of the content is icelandic and so contains a bunch of weird characters that I think are causing issues as I keep seeing:
Incomplete or invalid multibyte sequence encountered
I have tried adding flags such as --restrict-file-names=nocontrol but to no avail.
I have also tried using lftp but doesn't seem to make any difference.
According to wget manual
If you specify ‘nocontrol’, then the escaping of the control
characters is also switched off.
that is it as actually more permissive than default, bunch of weird characters suggest you have some issues with getting encoding right and therefore ascii seems to be best fit for your use case
The ‘ascii’ mode is used to specify that any bytes whose values are
outside the range of ASCII characters (that is, greater than 127)
shall be escaped. This can be useful when saving filenames whose
encoding does not match the one used locally.
As I do not have ability to test, please try it and write about result it give.
I am trying to use an environment variable which contains the file path, in NiFi Expression language. When I just give environment variable ${MY_VAR} for the file name, it is not getting resolved.
But if there is a space or some other character before the NiFi EL, it is being evaluated, but that will make an invalid file name. How to have this resolved without any extra characters.
So as per observation, when the whole content is just an EL it is not getting evaluated otherwise, it is.
PS: I am trying give the file name in Truststore Filename field in default StandardSSLContextService
You are encountering a bug in Apache NiFi. As Bryan pointed out, the truststore location field is not intended to support the Expression Language. The problem is stemming from an incorrect line at StandardSSLContextService:183 where the .evaluateExpressionAttributes() method is being invoked in the custom file validator, despite the comment a few lines above explaining the entire reason for this custom validator is because the default supports EL.
I ran a remote debugger and was able to evaluate ${TRUSTSTORE_LOCATION} using the environment variable TRUSTSTORE_LOCATION (which must be set before NiFi is started, because the VariableRegistry.ENVIRONMENT_SYSTEM_REGISTRY is only created by NotificationServiceManager which is invoked in RunNiFi:270). I was able to watch it correctly evaluate the environment variable to a file path, but then it was concatenated to the current running directory (.../nifi-assembly/target/nifi-1.4.0-SNAPSHOT-bin/nifi-1.4.0-SNAPSHOT/TRUSTSTORE_LOCATION) rather than being treated as an absolute/relative path because the property descriptor is unaware that this is the result of EL evaluation.
I have filed NIFI-4274 to document this bug. A workaround is to use a hard-coded truststore location in NiFi and use symlinks on your filesystem to point that at the actual file location if you do not know it at configure time.
I have an IzPack installer that takes in a lot of User Inputs and substitutes them in an XML file. This XML file is actually the configuration file for my application.
There is a major problem that I have hit and I cant move on from it.
In the Input fields (in the installer) user can enter any text and also special characters like & # % ' etc. These special characters messes up my XML file as they are no allowed in the XML syntax and needs to be escaped. for example for & one would need &
So far I have been asking the user to do this, as in escape the special characters themselves, but thats now working either.
Is there a way to have this done automatically? I really need a solution fast.
I am using IzPack V 4.1
You should use a proper XML Api (SAX, DOM) to generate the XML file, this will apply the correct encoding automatically. This may look more complicated first but guarantees that a well formed, syntactically correct file is written.
Searching for JAXP should give you a proper starting point.
When I create a directory using sytem user (vin.txt is my file)
create directory emp_dir1
AS "'C:\Documents and Settings\Administrator\Desktop\vin.txt'";
it creates it.
When I do the same using user Scott it gives an error for path of file that
"Identifier is too long"
but when I put this file path in single quotes instead of double quotes for scott, it creates it.
What is the reason behind?
A couple of things concern me about your question.
Firstly, regular users such as SCOTT should not be creating directories. The CREATE ANY DIRECTORY is extremely powerful, because it confers read/write privileges on any OS directory which is accessible to the oracle account; this is a massive security hole.
Secondly, the directory path must be just the path, without a file. We create files using UTL_FILE, Data Pump or whatever. A call to UTL_FILE.FOPEN() will fail if the passed DIRECTORY is actually a path to a file not an OS directory.
I cannot explain why the same statement executed successfully by SYSTEM fails when executed by SCOTT. I don't have 9i to hand, so I cannot test it. Please cut'n'paste the whole SQL*Plus output so that we can see what happens. As Peter has noted, your question appeared to contain a typo, so at the moment we cannot be certain that what you think is happening actually is what is happening.
Why are you using double-qoutes?
Strings in Oracle have single quotes, while double quotes can be used around column- and table-names.
I tried it using Oracle 10.2 (don't have any 9g around), and I can't reproduce this. It's never working, no matter what user I use.
When the string is as long as yours, I always get
ORA-00972: identifier is too long
When I try a shorter path (CREATE DIRECTORY emp_dir1 As "C:\vin.txt";) I get
ORA-01780: string literal required
If I wanted to create a string which is guaranteed not to represent a filename, I could put one of the following characters in it on Windows:
\ / : * ? | < >
e.g.
this-is-a-filename.png
?this-is-not.png
Is there any way to identify a string as 'not possibly a file' on Linux?
There are almost no restrictions - apart from '/' and '\0', you're allowed to use anything. However, some people think it's not a good idea to allow this much flexibility.
An empty string is the only truly invalid path name on Linux, which may work for you if you need only one invalid name. You could also use a string like "///foo", which would not be a canonical path name, although it could refer to a file ("/foo"). Another possibility would be something like "/dev/null/foo", since /dev/null has a POSIX-defined non-directory meaning. If you only need strings that could not refer to a regular file you could use "/" or ".", since those are always directories.
Technically it's not invalid but files with dash(-) at the beginning of their name will put you in a lot of troubles. It's because it has conflicts with command arguments.
I personally find that a lot of the time the problem is not Linux but the applications one is using on Linux.
Take for example Amarok. Recently I noticed that certain artists I had copied from my Windows machine where not appearing in the library. I check and confirmed that the files were there and then I noticed that certain characters in the folder names (Named for the artist) were represented with a weird-looking square rather than an actual character.
In a shell terminal the filenames look even stranger: /Music/Albums/Einst$'\374'rzende\ Neubauten is an example of how strange.
While these files were definitely there, Amarok could not see them for some reason. I was able to use some shell trickery to rename them to sane versions which I could then re-name with ASCII-only characters using Musicbrainz Picard. Unfortunately, Picard was also unable to open the files until I renamed them, hence the need for a shell script.
Overall this a a tricky area and it seems to get very thorny if you are trying to synchronise a music collection between Windows and Linux wherein certain folder or file names contain funky characters.
The safest thing to do is stick to ASCII-only filenames.