Recently getting this :

markp@marklap bin $ datecalc.jl
bash: /home/markp/bin/datecalc.jl: /usr/bin/julia: bad interpreter: Text file busy


Now I know for 100% certain that I DO have the source file open - I'm busy developing it and fixing bugs. So keeping it open, running it and then going straight to the error line and fixing is what I have done for YEARS.

So why all of a sudden is the system (bash ?) moaning that the file is open/busy ? So damn what ?

Anyone know how to get the old behaviour back ?

text file busy means (probably) a file is in use, cannot be overwritten. This is not a source [text] file, but an executable binary, which is actually running.

Well - actually it IS a text file. It is NOT a binary executable. And it is OPEN because I am editing it. I fully understand why it's giving me this "error" - point is that I do not perceive it as an error and I've been doing it forever. So why is it NOW an error. And how do I get the old (and gold) way back ?

no, you misunderstood. The text file busy means an executable is running and someone tries to overwrites the file itself. This is quite unfortunate, but the binaries has a part named txt, which is now protected and the system does not allow any modification on it.
see for example here: https://linuxhint.com/understanding_elf_file_format/

Check available disk space while editing.

You also see that error if you try to execute a file while some other process has that file open for writing. What is a bit strange, though, is that most editors don't hold the file open for writing except during the time it takes to write out the modified version, and even then the writing is usually done to a temporary filename that is than renamed back over the original. (Files with multiple hard links or accessed via a symlink have to be handled differently.)

If the file really is a text file used by an interpreter, you can get around the problem by explicitly invoking the interpreter rather than just asking the kernel to "execute" the file. Invoking a script by typing "myscript" or "./myscript" can cause a "Text file busy" error. Typing "bash myscript" or "bash ./myscript" would not, since it's just "some program reading the file" as far as the kernel is concerned. (Same for interpreters other than bash.)

2 members found this post helpful.

Yup - that worked. Very interesting. I'm mostly a Python developer - and I often do run scripts as 'python xxx.py'. But I've been fiddling a bit with Julia - which claims to be "as fast as C, as easy as Python" - and so I have "vi" open with the source and then running it in another shell window. I've just tested this with python3 and it too gives this error.

Even so - I've been writing python code professionally for 20+ years - and I CANNOT believe that this is the first time it has hit me. I've recently done a "current" upgrade - was maybe 4-6 months behind - and I'm sure this is new behaviour.

To be frank, I honestly do think this is a recent addition, and I don't like it one little bit. It looks fascist. Or windowsy. You know the attitude : "we know better than you". I far prefer the Linux (or maybe now only Slackware) attitude of "fine, you're the boss, be this on your head".

Ho ho - thanks Richard C. Well at least I'm not the first - even if that was 9 years back. Maybe I'm subconsciously doing things differently working from home under these lockdown rules.

It is doubly odd that the "rm" command there failed since, in Linux native filesystems at least, there is no restriction on removing a busy executable binary file. Remember that "rm" just unlinks the file from the directory, and the file remains on disk as long as any process has it open.

You can use "lsof -p ${PID}" (with the appropriate substitution for ${PID}) to see what files your editor process is keeping open. I just checked with emacs, and it does not keep the edited file open.

Yup - vi does in fact hold it open. I tried an editor called slickedit and that one does not.

ps -ef|grep sql_to_csv_new.py
markp 21954 21943 0 10:49 pts/11 00:00:00 vi sql_to_csv_new.py


lsof -p 21954
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
vi 21954 markp cwd DIR 259,3 20480 8536323 /home/markp
vi 21954 markp rtd DIR 259,3 4096 2 /
vi 21954 markp txt REG 259,3 35456 10297233 /usr/bin/nvi
... some junk deleted
vi 21954 markp mem REG 259,3 339912 11966925 /usr/lib64/locale/en_US.utf8/LC_CTYPE
vi 21954 markp 4uW REG 259,3 8696 8536639 /home/markp/sql_to_csv_new.py


and there is the culprit on the last line. So it's "vi" that holds it open and thus effectively locks it. Tut tut - I would have expected better from an old stalwart like that.

I do not understand. A file (a shell script) - which is opened with vi - can be executed without problems, you will never get that "text file busy" error message.
Also you can overwrite the file "behind" vi, and vi will detect the change and reflect on it.
Vi does not lock that file. You can even open several vi sessions on the same file, edit them.....

Maybe the OP actually uses -current instead of 14.2 ? vi is a symbolic link to elvis in 14.2. If it is a link to nvi in -current, then you get the Text file busy error.

1 members found this post helpful.

So - doing a man on "nvi" we see :

SET OPTIONS
There are a large number of options that may be set (or unset) to change the editor's behavior.
This section describes the options, their abbreviations and their default values.

In each entry below, the first part of the tag line is the full name of the option, followed by
any equivalent abbreviations. The part in square brackets is the default value of the option.
Most of the options are boolean, i.e. they are either on or off, and do not have an associated
value.

lock [on]
Attempt to get an exclusive lock on any file being edited, read or written.

So - the man page says that nvi DOES actually lock the file. Solved by RTFM.

And when did this arrive in Slackware Current ? .....

Mon Jan 13 00:11:55 UTC 2020
a/elvis-2.2_0-x86_64-5.txz: Rebuilt.
Don't make /usr/bin/{ex,vi} symlinks.
a/nvi-1.81.6-x86_64-1.txz: Added.
This is an implementation of the classic ex/vi text editor written by Keith
Bostic. Due to this having UTF8 support which elvis lacks, we'll have it
take over the ex/vi symlinks if they aren't already pointing to a different
choice. Note that the removal of vi/ex symlinks from the elvis and vim
packages might cause your ex/vi symlinks to point to this after all the ex/vi
packages have been upgraded. You can set them to your preferences using
pkgtool -> Setup -> vi-ex.

So - I wasn't going mad. This IS new behaviour.

3 members found this post helpful.

Ah. My link was misdirection at best. Please accept my apologies for that; I never intend to mislead people in this forum.