I aim to make an index of all files with a particular extension and store it into index.txt. I am getting all the right results but not getting the 'files' onto the new line, this is a snapshot of my code:
OutputStream f0 = new FileOutputStream("index.txt");
String ind[] = f.list(only); // logic for getting only relevant files
for(int i=0;i<ind.length;i++)
{
File n = new File(path + "/" +ind[i]);
System.out.println(ind[i]+ " is a " +exten +" file");
ind[i]+="\n"; // doesnt work
f0.write(ind[i].getBytes()); // here i am writing the filenames
}
is it due to the getBytes() function which overlooks the "/n" ? Please tell me what to do. I want to insert a new line everytime i exit the for loop.
One major edit: I am getting the desired result when I open the file with notepad++ or wordpad, but when i open the file with notepad i am getting the results on the same line. Please Explain this too!
Try writing:
System.getProperty("line.separator")
instead of \n
Instead of using an FileOutputStream I'd use a PrintWriter.
PrintWriter out = new PrintWriter("index.txt");
String ind[] = f.list(only); // logic for getting only relevant files
for(int i=0;i<ind.length;i++)
{
File n = new File(path + "/" +ind[i]);
System.out.println(ind[i]+ " is a " +exten +" file");
out.println(ind[i]);
}
Is there any reason you are working at such a low level of I/O in Java? First of all you should be using Writers instead of OutputStreams.
And then if you use PrintWriter you can do away with the getBytes piece:
PrintWriter f0 = new PrintWriter(new FileWriter("index.txt"));
And then later...
f0.print(ind[i]);
And finally to your question, outside the loop simply
f0.println();
There is a missing assumption here.
If you assume that your text file should have MS Windows line separators (meant for Windows platforms), then you should use \r\n.
If you assume that your text file should have Unix-like line separators (meant for GNU/Linux, AIX, Xenix, Mac OS X, FreeBSD, etc.), then you should use \n.
If you assume that your text file should have Mac oldschool line separators (meant for Mac OS up to version 9, Apple II family, OS-9, etc.), then you should use \r.
If you assume that your text file should have line separators of the kind of the platform your program is run from, then you should use System.getProperty("line.separator") (or print the new line with a .println()).
try this,
FileWriter.write("\r\n");
Related
Like the title says I'm not able to read the contents of a file (csv file) while running the same code on a linux container
private Set<VehicleConfiguration> loadConfigurations(Path file, CodeType codeType) throws IOException {
log.debug("File exists? " + Files.exists(file));
log.debug("Path " + file.toString());
log.debug("File " + file.toFile().toString());
log.debug("File absolute path " + file.toAbsolutePath().toString());
String line;
Set<VehicleConfiguration> configurations = new HashSet<>(); // this way we ignore duplicates in the same file
try(BufferedReader br = new BufferedReader(new FileReader(file.toFile()))){
while ((line = br.readLine()) != null) {
configurations.add(build(line, codeType));
}
}
log.debug("Loaded " + configurations.size() + " configurations");
return configurations;
}
The logs return "true" and the path for the file in both systems (locally on windows and on a linux docker container). On windows it loads "15185 configurations" but on the container it loads "0 configurations".
The file exists on linux, I use bash and check it myself. I use the head command and the file has lines.
Before this I tried with Files.lines like so:
var vehicleConfigurations = Files.lines(file)
.map(line -> build(line, codeType))
.collect(Collectors.toCollection(HashSet::new));
But this has a problem (on container only) regarding the contents. It reads the file but not the whole file, it reaches a given line (say line 8000) and does not read it completely (reads about half a line before the comma separator). Then I get a java.lang.ArrayIndexOutOfBoundsException because my build method tries to split then line and I access index 1 (which it doesn't have, only 0):
private VehicleConfiguration build(String line, CodeType codeType) {
String[] cells = line.split(lineSeparator);
var vc = new VehicleConfiguration();
vc.setVin(cells[0]);
vc.setCode(cells[1]);
vc.setType(codeType);
return vc;
}
What could be the issue? I don't understand how the same code (in Java) works on Windows but not on a Linux container. It makes no sense.
I'm using Java 11. The file is copied using volumes in a docker-compose file like this:
volumes:
- ./file-sources:/file-sources
I then copy the file (using cp command on the linux container) from file-sources to /root because that's where the app is listening for new files to arrive. File contents are then read with the methods I described. Example file data (does not have weird characters):
Thanks in advance.
UPDATE: Tried with newBufferedReader method, same result (works on windows, doesn't work on linux container):
private Set<VehicleConfiguration> loadConfigurations(Path file, CodeType codeType) throws IOException {
String line;
Set<VehicleConfiguration> configurations = new HashSet<>(); // this way we ignore duplicates in the same file
try(BufferedReader br = Files.newBufferedReader(file)){
while ((line = br.readLine()) != null) {
configurations.add(build(line, codeType));
}
}
log.debug("Loaded " + configurations.size() + " configurations");
return configurations;
}
wc -l in the linux container (in /root) returns: 15185 hard_001.csv
Update: This is no solution but I found out that by dropping the files directly on the file-sources folder and make that folder the folder that the code listens to, the files are read. So basically, it seems the problem is more apparent with using cp/mv inside the container to another folder. Maybe the file is read before it is fully copied/moved and that's why it reads 0 configurations?
There are a few methods in java you should never use. ever.
new FileReader(File) is one of them.
Any time that you have a thing that represents bytes and somehow chars or Strings fall out, or vice versa? Don't ever use those, unless the spec of said method explicitly points out that it always uses a pre-set charset. Almost all such methods use the 'system default charset' which means that the operation depends on the machine you run it on. That is shorthand for 'this will fail, and your tests won't catch it'. Which you don't want.
Which is why you should never use these things.
FileReader has been fixed (there is a second constructor that takes a charset), but that's only since JDK11. You already have the nice new API, why do you switch back to the dinky old File API? Don't do that.
All the various methods in Files, such as Files.newBufferedReader, are specced to do UTF-8 if you don't specify (in that way, Files is more useful, and unlike most other java core libraries). Thus:
try (BufferedReader br = Files.newBufferedReader(file)) {
which is just.. better.. than your line.
Now, it'll probably still fail on you. But that's good! It'll also fail on your dev machine. Most likely, the file you are reading is not, in fact, in UTF_8. This is the likely guess; most linuxen are deployed with a UTF_8 default charset, and most dev machines are not; if your dev machine is working and your deployment environment isn't, the obvious conclusion is that your input file is not UTF_8. It does not need to be what your dev machine has a default either; something like ISO_8859_1 will never throw exceptions, but it will read gobbledygook instead. Your code may seem to work (no crashes), but the text you read is still incorrect.
Figure out what text encoding you got, and then specify it. If it's ISO_8859_1, for example:
try (BufferedReader br = Files.newBufferedReader(file, StandardCharsets.ISO_8859_1)) {
and now your code no longer has the 'works on some machines but not on others' nature.
Inspect the line where it fails, in a hex editor if you have to. I bet you dollars to donuts there will be a byte there which is 0x80 or higher (in decimal, 128 or higher). Everything up to and including 127 tends to mean the exact same thing in a wide variety of text encodings, from ASCII to any ISO-8859 variant to UTF-8 Windows Cp1252 to macroman to so many other things, so as long as it's all just plain letters and digits, having the wrong encoding is not going to make any difference. But once you get to 0x80 or higher they're all different. Armed with that byte + some knowledge of what character it is supposed to be is usually a good start in figuring out what encoding that text file is in.
NB: If this isn't it, check how the text file is being copied from your dev machine to your deployment environment. Are you sure it is the same file? If it's being copied through a textual mechanism, charset encoding again can be to blame, but this time in how the file is written, instead of how your java app reads it.
I have a programming mini competition tomorrow and we will be required to create our program on a flash drive given. The judges won't edit our code so it runs and I am worried that the flash drive letter will change and then my program won't be able to locate the text file it needs to read in.
I have always used paths for my flash drive like this:
FileReader file = new FileReader("E:/BPA/Crypto/input.txt");
Is there a way for me to guarantee my program will be able to read in the text file despite if the letter name for my flash drive isn't the same on the judges computer as it was on mine? Thanks!
You may
Put the file inside your sources
Use Class.getResourceAsStream(String name) to get InputStream of the file
For example, if you have class x.y.z.A
Copy input.txt to src folder into x/y/z package
Get corresponding InputStreamReader as InputStreamReader fileStream = new InputStreamReader(A.class.getResourceAsStream("input.txt"));
If you aren't sure what drive the file will be you could do something like this
char drive = 'A';
String filePath = ":/BPA/Crypto/input.txt";
while(drive != 'Z')
{
try{
Scanner readFromFile = new Scanner(new File(drive + filePath));
readFromFile.close(); //add this if you simply want the path or drvie letter
break;
}catch(FileNotFoundException error)
{
System.out.println("Drive: " + drive + " did not contained file in " + drive + filePath);
}
drive += 1;
}
Basically the idea is to attempt to open the file for reading from different drives starting at A up until Y. Obviously you can go further but I am going to assume that drives A-Y would safely exhaust all the possible drives on where ever you are running your software.
By the time you get our of the While loop the variable "drive" will contain the correct letter of the drive you want. You can modify it to be a function that returns the letter, or perhaps the file path, or simply use it once whenever you try to read from the text file. Up to you.
I have a.txt list trying to move the first line to the last line in Java
I've found scripts to do the following
Find "text" from input file and output to a temp file. (I could set
"text" to a string buffRead.readLine ??) and then...
delete the orig file and rename the new file to the orig?
Please for give me I am new to Java but I have done a lot of research and can't find a solution for what I thought would be a simple script.
Because this is Java and concerns file IO, this is a non-trivial setup. The algorithm itself is simple, but the symbols required to do so are not immediately evident.
BufferedReader reader = new BufferedReader(new FileReader("fileName"));
This gives you an easy way to read the contents of the file fileName.
PrintWriter writer = new PrintWriter(new FileWriter("fileName"));
This gives you a simple way to write to the file. The API to do so is the exact same as System.out when you use a PrintWriter, thus my choice to use one here.
At this point its a simple matter of reading the file and echoing it back in the correct order.
String text = reader.readLine();
This saves the first line of the file to text.
while (reader.ready()) {
writer.println(reader.readLine());
}
While reader has text remaining in it, print the lines into the writer.
writer.println(text);
Print the line that you saved at the start.
Note that if your program does anything else (and it's just a good habit anyway), you want to close your IO streams to avoid leaking resources.
reader.close();
writer.close();
Alternatively, you could also wrap the entire thing in a try-with-resources to perform the same cleanup automatically.
Scanner fileScanner = new Scanner(myFile);
fileScanner.nextLine();
This will return the first line of text from the file and discard it because you don't store it anywhere.
To overwrite your existing file:
FileWriter fileStream = new FileWriter("my/path/for/file.txt");
BufferedWriter out = new BufferedWriter(fileStream);
while(fileScanner.hasNextLine()) {
String next = fileScanner.nextLine();
if(next.equals("\n") out.newLine();
else out.write(next);
out.newLine();
}
out.close();
Note that you will have to be catching and handling some IOExceptions this way. Also, the if()... else()... statement is necessary in the while() loop to keep any line breaks present in your text file.
Add the same line to the last line of this file have a look into this link https://stackoverflow.com/a/37674446/6160431
I have a tomcat running on a Linux server.
My webapp is creating text files that must be imported by another external system that accepts DOS/Windows formatted files.
FileWriterWithEncoding writer;
writer = new FileWriterWithEncoding(file,"UTF-8", true);
PrintWriter printer = new PrintWriter(writer);
How can I create such DOS formatted files with Java on a Linux server?
Thank you.
Make sure that the line endings you write are "\r\n", this is the Windows way of writing them (carriage return character + line feed character) .
I have a Java app that writes to a file with:
BufferedWriter bw = new BufferedWriter(new FileWriter(outputFile));
bw.write(line + lineTermination);
Line termination is defined as:
\r\n
I get the odd, mysterious blank line inserted into my file.
I get no extra lines if I change my code to:
bw.write(line);
bw.newLine();
But I want to force a specific line ending, not use System property. Clients specifically request a line ending character - some even have |. Its not a viable fix to just use \n.
Here is an snippet of the data with missing line:
"KABE","14/01/11","14:35","14:56","1987","US","SS","CO","MARRIED WITH CHILDREN","","EINE SCHRECKLICH NETTE FAMILIE","","N","10","","12","O'NEILL ED","13","SAGAL KATEY"
"PRO7","14/01/11","14:35","14:55","2001","US","SS","CO","SCRUBS","","SCRUBS DIE ANFAENGER","","C","10","BERNSTEIN ADAM","12","BRAFF ZACH","13","CHALKE SARAH"
Thanks for your time :-)
You can call
System.setProperty("line.separator", "\r\n");
in order to set the system property inside your code.