What command/program can I execute in a script to call the application associated with a mimetype/file extension? Like when you are in a File browser and you "open" a file. The syntax in a script file would be: <start-app> <a-file> The coding would be: <start-app> $1
For example, if <a-file> were: Something.html then <start-app> would start a browser and have it open Something.html
Another example, if <a-file> were: Picture.jpg then <start-app> would start an image program and have it open Picture.jpg
/etc/mime.types associates mime types with file extensions, but not with applications. Unfortunately, association with applications is done via the GUI desktops - both Gnome and KDE have their own distinct databases, and if your running a text-only system, you're out of luck.
Customer surveys are for companies who didn't pay proper attention to begin with.
Joined: Aug 10, 2005
Thanks for the reply. One of my applications is a java program to start a browser to read from a URL. Another java program gets the values of the environment variables. On Windows I use cmd or command with SET and read and parse the response. Is this possible on Linux(unbuntu)?
My applications use the Runtime.exec() method to execute a program. I'm looking for what to execute on Linux.
What is a text-only system?
Joined: Aug 10, 2005
Also in looking at the files for mimetypes (I think they were Desktop configuration) there is an entry: Exec=<commandline> that is executed in nautilus when the file is opened.
Seriously, X is not an integral part of Linux. Like Windows 9x and earlier, there's a command-line OS underneath the GUI. Except that unlike DOS, command-line Unix/Linux is a full-strength multi-tasking OS.
You can run Linux perfectly fine without a Window manager. I have a 200MHz server with only 98MB of RAM that handles a lot of my workload. But to run X +Gnome or KDE on a modern Linux release would require over 100MB just for the GUI itself. So I don't do windowing on it.
Similarly, the environment is not an integral part of the Linux OS either - it's a function of the shell. In theory this means that different shells could have radically different ideas of environment, but that was a little too much, so while different sets of environment variables may get set depending on the shell and on how the shell was launched, the basic concept and application access is pretty much standard.
The BASH shell has a builtin command named "set" (lower-case, not "SET") that will emit the current environment to stdout in the form of a set of lines in "var=value expression" format. So an easy way to tell an application what the environment variables are is to run set and pipe the results into the app. In the case of Runtime.exec, that would actually mean running bash as the executable, which is something I'd rather not do. Aside from everything else, what that subshell returns as its environment variables isn't necessarily going to be exactly like the environment variables in the shell that your JVM is running under.
An easier way in Java 1.5 and later is to use the java.lang.System.getenv() method. This will return a read-only copy of your environment in a Java Map.
It was a long hard struggle to get that function in there. Sun argued that environments are OS-specific. Developers argued that almost every OS has an environment. Finally Sun gave in.
But java properties are recommended over environment variables in Java apps. Not only are they more java-portable, they're more manageable.