0

I'm attempting to run an old script which takes an .mdb file and converts it into a MySQL database. However, I'm running into an issue where I receive the following error.

  File "/usr/lib64/python2.7/subprocess.py", line 568, in check_output
process = Popen(stdout=PIPE, *popenargs, **kwargs)
  File "/usr/lib64/python2.7/subprocess.py", line 711, in __init__
errread, errwrite)
  File "/usr/lib64/python2.7/subprocess.py", line 1327, in _execute_child
raise child_exception
OSError: [Errno 2] No such file or directory

I have attempted to research this error, but all I found was fixes where the item was not correctly formatted as a list. So, I've modified the affected code where subprocess.py is called, and changed it to the following:

def get_external_command_output(command):
    args = shlex.split(command)
    print "################"
    print type(args), args
    ret = subprocess.check_output(args) # this needs Python 2.7 or higher
    return ret

Which in turn returns the same error, but also the below message is printed:

<type 'list'> ['mdb-tables', '-1', '/mnt/data/General/Genit/WIP/IL_Orders.mdb']

So I can safely say that the arguments are correctly formatted as a list. I'm really unsure how else to tackle this issue, because all the help forums I've found suggest the same issue. The argument isn't a list. However, I can see that mine is.

Could anybody provide some guidance here? Many thanks.

Shadow
  • 33,525
  • 10
  • 51
  • 64
wonk
  • 92
  • 1
  • 10
  • `mdb-tables` isn't on your path – Peter Wood Jul 19 '18 at 15:33
  • @PeterWood as in, the module isn't installed? I'm sure I should get a different error in that case – wonk Jul 20 '18 at 08:19
  • `subprocess` is for creating operating system processes, not necessarily python processes. `mdb-tables -1 /mnt/data/General/Genit/WIP/IL_Orders.mdb` needs to be callable from a command line prompt. – Peter Wood Jul 20 '18 at 09:32
  • [`mdb-tables`](https://www.systutorials.com/docs/linux/man/1-mdb-tables/) needs to be on your system path. – Peter Wood Jul 20 '18 at 09:32

1 Answers1

0

There can be number of reasons for this. The error comes from your underlying OS (ENOENT).

The easiest to would be to try running the same thing:

mdb-tables -1 /mnt/data/General/Genit/WIP/IL_Orders.mdb

(or just mdb-tables really) and see what happens, what complain you get from your shell.

Among possible reasons would be:

As mentioned by Peter Wood in the comments. If you just pass an executable name to run, it must be located in one of the directories listed in your PATH environmental variable. Or, you have to use either path to the executable which is either absolute or relative to current working directory (based on where you ran the parent from or cwd argument passed to subprocess.check_output call). E.g. ./mdb-tables if in the same directory where you were when you ran the parent script or to which cwd was set.

It is also possible. Esp. if it's an older script. That you have specified an interpreter that no longer exists on your host. In that case the same error (ENOENT) would be raised. You might see a slightly different error message (hinting at bad interpreter) if executed directly from shell, but it would look identical when called as subprocess from python.

You've hinted mdb-tables is also a script. But otherwise previous paragraph would also hold true for dynamically linked ELF binaries. If they were built with and expected a version (path) of dynamic linker (their interpreter) no longer available on the system. You can print path of the expected dynamic linker binary for instance by running objdump -sj .interp BINARY_IN_QUESTION.

Ondrej K.
  • 8,841
  • 11
  • 24
  • 39
  • tl;dr I'm a moron and didn't consider the fact that mdb-tools might not exist anymore. It seems we lost the module during a recent server changeover because when I went over and reinstalled all our pip modules I forgot about things installed with yum. My code was fine and unchanged, it was just relying on something that didn't exist. This answer made it click for me, so thank you. My bad :( – wonk Jul 23 '18 at 08:16
  • Hehe, yes, the file not being there at all... Also a possible cause. :) – Ondrej K. Jul 23 '18 at 08:17