虽然它并不漂亮,但我通过在启动应用程序之前将dir / ls的输出管道连接到文件并传入文件名,解决了这种问题。
如果你需要在应用程序中执行此操作,你可以只使用system.exec(),但它会产生一些恶心。
你问。第一种形式将非常快,第二种形式也应该非常快。
确保每行执行一个项目(裸露,无修饰,无图形),所选命令的完整路径和递归选项。
编辑:
30分钟只是为了得到一个目录列表,哇。
我突然想到,如果你使用exec(),你可以让它的stdout重定向到管道中,而不是把它写到一个文件中。
如果这样做,则应立即开始获取文件,并能够在命令完成之前开始处理。
这种互动实际上可能会减慢速度,但也许不会 - 你可以试一试。
哇,我刚刚为你找到了.exec命令的语法,并遇到了这个,可能正是你想要的(它使用exec和“ls”列出了一个目录,并将结果管道化到你的程序中进行处理):很好的回溯链接(Jörg在注释中提供了替换Oracle破坏的sun的这个目录)
无论如何,这个想法很简单,但正确的代码很烦人。我会从互联网上偷一些代码并破解它们 - brb
/**
* Note: Only use this as a last resort! It's specific to windows and even
* at that it's not a good solution, but it should be fast.
*
* to use it, extend FileProcessor and call processFiles("...") with a list
* of options if you want them like /s... I highly recommend /b
*
* override processFile and it will be called once for each line of output.
*/
import java.io.*;
public abstract class FileProcessor
{
public void processFiles(String dirOptions)
{
Process theProcess = null;
BufferedReader inStream = null;
// call the Hello class
try
{
theProcess = Runtime.getRuntime().exec("cmd /c dir " + dirOptions);
}
catch(IOException e)
{
System.err.println("Error on exec() method");
e.printStackTrace();
}
// read from the called program's standard output stream
try
{
inStream = new BufferedReader(
new InputStreamReader( theProcess.getInputStream() ));
processFile(inStream.readLine());
}
catch(IOException e)
{
System.err.println("Error on inStream.readLine()");
e.printStackTrace();
}
} // end method
/** Override this method--it will be called once for each file */
public abstract void processFile(String filename);
} // end class
感谢 IBM 的代码捐赠者