[arch-general] Holy Cow -- What happened to bash / vi??
Listmates, I updated to [testing] and now I am having strange behavior from either bash or vi. (the new vi has many issues, but ignoring those for the moment) I have one of my simple parse scripts open in vi in one console window and I make a few changes to a sed expression, then :w to save the changes and [shift]-> in konsole to get to a second konsole window to run the script and bash won't let me??? I get this new message: [00:08 archangel:/etc] # noc fstab bash: /usr/local/bin/noc: /bin/bash: bad interpreter: Text file busy WTF?? Here is the entire script: [00:11 archangel:/etc] # cat /usr/local/bin/noc #!/bin/bash if [[ -z "$1" ]]; then echo -e "\n\n\tUsage: ${0##*/} <filename>" echo -e "\n\n\tParses the text file <filename> and removes all blank lines and all lines beginning \ \n\twith a first non-blank character of [# ; !] or two character of '//' or '/*'. \ \n\tIt is useful for looking at configuration files without all the comments. \n" exit 1 fi # updated to handle php, C and C++ // comments sed -e '/^[/s]*$/d' -e '/^\s*[#;!]/d' -e '/^\s*[/*]/d' -e 's/[^:]\/\/.*$//' <$1 exit 0 Text file busy?? It's a text file, it's not busy, it's either saved or you get what was present the last time it was saved, but it certainly isn't busy. Apparently bash is not looking for vi tmp file and calling it busy if found??? What gives??? Yep, that is exactly what is happening. If i quit vi and try the script: [00:16 archangel:/etc] # noc fstab none /dev/pts devpts defaults 0 0 none /dev/shm tmpfs defaults 0 0 If I open it back up in vi and then try to run it: [00:16 archangel:/etc] # noc fstab bash: /usr/local/bin/noc: /bin/bash: bad interpreter: Text file busy How (and where) do I tell bash or vi not to do this. I don't even know where to start looking.... (I tested on another box that I have NOT updated anything from [testing] and vi and bash both work properly. Any help would be appreciated, thanks. -- David C. Rankin, J.D.,P.E. Rankin Law Firm, PLLC 510 Ochiltree Street Nacogdoches, Texas 75961 Telephone: (936) 715-9333 Facsimile: (936) 715-9339 www.rankinlawfirm.com
On Mon, Jun 22, 2009 at 8:26 AM, David C. Rankin < drankinatty@suddenlinkmail.com> wrote:
Listmates,
I updated to [testing] and now I am having strange behavior from <http://www.rankinlawfirm.com>...
Any partiular reason you did that? Its likely BOTH vi and bash are to blame as both are entirely different from the ones in extra. -- Greg
On Monday 22 June 2009 12:42:18 am Grigorios Bouzakis wrote:
On Mon, Jun 22, 2009 at 8:26 AM, David C. Rankin <
drankinatty@suddenlinkmail.com> wrote:
Listmates,
I updated to [testing] and now I am having strange behavior from <http://www.rankinlawfirm.com>...
Any partiular reason you did that?
yes, testing dmraid 1.0.15rc
Its likely BOTH vi and bash are to blame as both are entirely different from the ones in extra.
I will downgrade vi. If that is what the future of vi looks like, I don't want any part of it. Changes that dramatic ought to be forked. -- David C. Rankin, J.D.,P.E. Rankin Law Firm, PLLC 510 Ochiltree Street Nacogdoches, Texas 75961 Telephone: (936) 715-9333 Facsimile: (936) 715-9339 www.rankinlawfirm.com
On Mon 22 Jun 2009 03:09 -0500, David C. Rankin wrote:
I will downgrade vi. If that is what the future of vi looks like, I don't want any part of it. Changes that dramatic ought to be forked.
You were previously using vim named 'vi'. The new one is actually a fork of vi called nvi.
On Mon, Jun 22, 2009 at 07:47, Loui Chang<louipc.ist@gmail.com> wrote:
On Mon 22 Jun 2009 03:09 -0500, David C. Rankin wrote:
I will downgrade vi. If that is what the future of vi looks like, I don't want any part of it. Changes that dramatic ought to be forked.
You were previously using vim named 'vi'. The new one is actually a fork of vi called nvi.
I don't understand why anyone would use any vi. Use vim instead...
On Mon, 22 Jun 2009 08:02:43 -0400 Daenyth Blank <daenyth+arch@gmail.com> wrote:
On Mon, Jun 22, 2009 at 07:47, Loui Chang<louipc.ist@gmail.com> wrote:
On Mon 22 Jun 2009 03:09 -0500, David C. Rankin wrote:
I will downgrade vi. If that is what the future of vi looks like, I don't want any part of it. Changes that dramatic ought to be forked.
You were previously using vim named 'vi'. The new one is actually a fork of vi called nvi.
I don't understand why anyone would use any vi. Use vim instead...
One of the things I've learned from maintaining stuff: never underestimate the diversity of requirements/values people have. If you look at the suckless community for instance, you'll find many of them who consider vim bloatware. Dieter
On Mon, Jun 22, 2009 at 7:02 AM, Daenyth Blank<daenyth+arch@gmail.com> wrote:
On Mon, Jun 22, 2009 at 07:47, Loui Chang<louipc.ist@gmail.com> wrote:
On Mon 22 Jun 2009 03:09 -0500, David C. Rankin wrote:
I will downgrade vi. If that is what the future of vi looks like, I don't want any part of it. Changes that dramatic ought to be forked.
You were previously using vim named 'vi'. The new one is actually a fork of vi called nvi.
I don't understand why anyone would use any vi. Use vim instead...
I've always harped on this point. I use "vim". Vim is the name of the application that I use. Vim just happens to be largely vi compatible, but I still use vim.
Excerpts from Aaron Griffin's message of Mon Jun 22 12:27:01 -0400 2009:
On Mon, Jun 22, 2009 at 7:02 AM, Daenyth Blank<daenyth+arch@gmail.com> wrote:
On Mon, Jun 22, 2009 at 07:47, Loui Chang<louipc.ist@gmail.com> wrote:
On Mon 22 Jun 2009 03:09 -0500, David C. Rankin wrote:
I will downgrade vi. If that is what the future of vi looks like, I don't want any part of it. Changes that dramatic ought to be forked.
You were previously using vim named 'vi'. The new one is actually a fork of vi called nvi.
I don't understand why anyone would use any vi. Use vim instead...
I've always harped on this point. I use "vim". Vim is the name of the application that I use. Vim just happens to be largely vi compatible, but I still use vim.
Yeah, I'm not a huge fan of running "vi" and expecting vim. Sounds a bit like running "mozilla" and expecting "firefox" or... something. -AT -- Andrei Thorp, Developer: Xandros Corp. (http://www.xandros.com) Freedom begins when you tell Mrs. Grundy to go fly a kite.
David C. Rankin wrote: <snip>
I get this new message:
[00:08 archangel:/etc] # noc fstab bash: /usr/local/bin/noc: /bin/bash: bad interpreter: Text file busy
<snip>
Text file busy?? It's a text file, it's not busy, it's either saved or you get what was present the last time it was saved, but it certainly isn't busy.
<snip> "Text file busy" is not related with text files :) Text refers to the "text section" of the executable. The text section of an executable is where the code resides, in other words the real program. This message appears when a process is running and you try to overwrite it, for example: [root@gerardo ~]# lsof -n | grep "sbin/init" init 1 root txt REG 8,1 31352 1079262 /sbin/init <<< note the 'txt' at 4th field. [root@gerardo ~]# echo 'hola' > /sbin/init -bash: /sbin/init: Text file busy But in this case is different, you are open(2) a file in read/write mode (O_RDWR), and you tried to execute it execve(2). This is impossible. Again lsof help to view this: [djgera@gerardo ~]$ vi coco.sh [djgera@gerardo ~]$ lsof -n | grep coco.sh vi 4127 djgera 4uW REG 8,6 32 113481 /home/djgera/coco.sh #### see the 'W' in 4th field. [djgera@gerardo ~]$ ./coco.sh bash: ./coco.sh: /bin/bash: bad interpreter: Text file busy Another simple example: [djgera@gerardo ~]$ cat coco.sh #!/bin/bash echo "Hola mundo!" [djgera@gerardo ~]$ cat coco.c #include <stdio.h> #include <unistd.h> #include <sys/types.h> #include <sys/stat.h> #define __USE_GNU #include <fcntl.h> int main(int argc, char *argv[]) { int coco; coco = open("./coco.sh", O_RDWR); sleep(60); close(coco); return(0); } [djgera@gerardo ~]$ gcc coco.c -o coco [djgera@gerardo ~]$ ./coco & [1] 4234 [djgera@gerardo ~]$ lsof -n | grep coco.sh coco 4234 djgera 3u REG 8,6 32 113481 /home/djgera/coco.sh #### See the 'u' in 4th field. [djgera@gerardo ~]$ ./coco.sh bash: ./coco.sh: /bin/bash: bad interpreter: Text file busy Good Luck! (sorry my english) -- Gerardo Exequiel Pozzi ( djgera ) http://www.djgera.com.ar KeyID: 0x1B8C330D Key fingerprint = 0CAA D5D4 CD85 4434 A219 76ED 39AB 221B 1B8C 330D
Gerardo Exequiel Pozzi wrote:
David C. Rankin wrote:
<snip>
I get this new message:
[00:08 archangel:/etc] # noc fstab bash: /usr/local/bin/noc: /bin/bash: bad interpreter: Text file busy
<snip>
Text file busy?? It's a text file, it's not busy, it's either saved or you get what was present the last time it was saved, but it certainly isn't busy.
<snip>
"Text file busy" is not related with text files :)
Text refers to the "text section" of the executable. The text section of an executable is where the code resides, in other words the real program.
This message appears when a process is running and you try to overwrite it, for example:
[root@gerardo ~]# lsof -n | grep "sbin/init" init 1 root txt REG 8,1 31352 1079262 /sbin/init <<< note the 'txt' at 4th field. [root@gerardo ~]# echo 'hola' > /sbin/init -bash: /sbin/init: Text file busy
But in this case is different, you are open(2) a file in read/write mode (O_RDWR), and you tried to execute it execve(2). This is impossible.
Again lsof help to view this:
[djgera@gerardo ~]$ vi coco.sh
[djgera@gerardo ~]$ lsof -n | grep coco.sh vi 4127 djgera 4uW REG 8,6 32 113481 /home/djgera/coco.sh #### see the 'W' in 4th field. [djgera@gerardo ~]$ ./coco.sh bash: ./coco.sh: /bin/bash: bad interpreter: Text file busy
Another simple example:
[djgera@gerardo ~]$ cat coco.sh #!/bin/bash
echo "Hola mundo!" [djgera@gerardo ~]$ cat coco.c #include <stdio.h> #include <unistd.h> #include <sys/types.h> #include <sys/stat.h> #define __USE_GNU #include <fcntl.h>
int main(int argc, char *argv[]) { int coco; coco = open("./coco.sh", O_RDWR); sleep(60); close(coco); return(0); } [djgera@gerardo ~]$ gcc coco.c -o coco [djgera@gerardo ~]$ ./coco & [1] 4234 [djgera@gerardo ~]$ lsof -n | grep coco.sh coco 4234 djgera 3u REG 8,6 32 113481 /home/djgera/coco.sh #### See the 'u' in 4th field. [djgera@gerardo ~]$ ./coco.sh bash: ./coco.sh: /bin/bash: bad interpreter: Text file busy
Good Luck!
(sorry my english)
Btw: if you execute the script via "bash coco.sh" will work ;) And maybe my example is ambiguous, if the openned file is not a script also can not be executed. Example: (changing the open line to /bin/ping, and executing as root [djgera@gerardo ~]$ ping bash: /bin/ping: Text file busy -- Gerardo Exequiel Pozzi ( djgera ) http://www.djgera.com.ar KeyID: 0x1B8C330D Key fingerprint = 0CAA D5D4 CD85 4434 A219 76ED 39AB 221B 1B8C 330D
participants (8)
-
Aaron Griffin
-
Andrei Thorp
-
Daenyth Blank
-
David C. Rankin
-
Dieter Plaetinck
-
Gerardo Exequiel Pozzi
-
Grigorios Bouzakis
-
Loui Chang