PDA

View Full Version : Open/Executing Files on Linux



MBex
2nd June 2011, 10:28
Hello,

actually i have a problem opening or executing a file on Linux. This means if the user choose maybe a text file, i need to open the text file. If the user choose a binary like the QtCreator i need to start the application.

On Windows its just easy by checking QFileInfo().isExecutable() and then calling QDesktopService::openUrl() or QProcess::execute().

But on Linux that does not work as i expect. isExecutable() is in this case just useless on linux. Calling QDesktopService::openUrl() for a binary does obviously not work and QProcess::execute() cant open a text file.

Does anyone have a suggestion how i can handle both situations correctly?

greets

arturo182
2nd June 2011, 12:35
Maybe you could check permissions, executable files will have the "x" permission and text files won't.

SixDegrees
2nd June 2011, 16:57
Maybe you could check permissions, executable files will have the "x" permission and text files won't.

Any file can have the exexcutable bit set under linux; it doesn't guarantee that the file is an exectable program.

Linux does, however, have the excellent 'file' utitlity which can provide detailed information on thousands of file types.

ChrisW67
2nd June 2011, 23:17
The UNIX "file" command is not that reliable on its own, and certainly not reliably portable given that strings change with versions and Linux flavours. First a binary executable:


$ cp /bin/ls /tmp
$ ls -l /tmp/ls
-rwxr-xr-x 1 chrisw users 92072 Jun 3 08:11 /tmp/ls
$ file /tmp/ls
/tmp/ls: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.9, stripped
# Remove execute permission
$ chmod a-x /tmp/ls
$ ls -l /tmp/ls
-rw-r--r-- 1 chrisw users 92072 Jun 3 08:11 /tmp/ls
$ file /tmp/ls
/tmp/ls: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.9, stripped
# Same description but NOT executable

Same problem with shell scripts.


$ ls -l /tmp/verifyCD.sh
-rwxr--r-- 1 chrisw users 611 Jun 3 08:06 verifyCD.sh
$ file /tmp/verifyCD.sh
/tmp/verifyCD.sh: Bourne-Again shell script text executable
# ^^ good ID, and file is executable
$ chmod a-x /tmp/verifyCD.sh
$ ls -l /tmp/verifyCD.sh
-rw-r--r-- 1 chrisw users 611 Jun 3 08:06 verifyCD.sh
$ file /tmp/verifyCD.sh
/tmp/verifyCD.sh: Bourne-Again shell script text executable
# Attempting to execute this will fail. Huh? ^^^

If the execute bit is set in the file permissions (and it is a regular file) then you should try to execute it. If the user has set the bit on something that is not executable then that, I believe, is the user's problem.

SixDegrees
2nd June 2011, 23:43
If the user has set the bit on something that is not executable then that, I believe, is the user's problem.

Sort of. Directories always have the execute bit set. And I've seen more than my share of applications that have had their execute bits turned off for one reason or another.

I agree, though, that the application should simply try to launch whatever file is selected, since there's also no guarantee that the file will run correctly even if it is a legitimate executable file if there are missing dynamic libraries or other resources. This is true on Windows as well.

ChrisW67
3rd June 2011, 00:15
Directories always have the execute bit set.
Indeed, that's why I stipulated that it be a regular file. This also precludes trying to execute character and block device nodes, named pipes (sockets) etc.