bug-coreutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Fw: side-effect implementing the mv command


From: Derick Centeno
Subject: Fw: side-effect implementing the mv command
Date: Thu, 4 Mar 2010 05:38:13 -0500


Begin forwarded message:

Date: Wed, 3 Mar 2010 13:58:59 -0500
From: Derick Centeno <address@hidden>
To: Eric Blake <address@hidden>
Subject: Re: side-effect implementing the mv command


On Wed, 03 Mar 2010 08:08:55 -0700
Eric Blake <address@hidden> wrote:

> [please keep replies on the list, so that others may chime in]
> 
> According to Derick Centeno on 3/2/2010 5:50 PM:
> >> I'm not quite sure what you saw or what you are asking.  If this is still
> >> an issue for you, could you post more context, such as some 'ls -l *.so'
> >> listings in both the source and destination directories?  Also, are the
> >> two directories on the same disk, where rename(2) would work, or was it a
> >> cross-device move, where mv(1) has to create the copy before deleting the
> >> original?
> >>
> > 
> > Thanks for your response on this query, Eric.
> > 
> > Background:
> > I had downloaded a java plugin designed for PowerPC systems, as I'm running
> > Linux on a PowerPC.  That plugin is known as:  libjavaplugin_oji.so
> > Originally it was installed into: /opt/ibm/java-ppc-60/jre/plugin/ppc/ns7
> > 
> > It is supposed to be moved into: /usr/lib/mozilla/plugins
> > 
> > When I executed the mv command from within the ns7 directory by doing:
> > $ sudo mv ./libjavaplugin_oji.so /usr/lib/mozilla/plugins
> 
> Maybe the issue is related to the fact that you were trying to move a
> symlink, rather than an actual file?  If the symlink contains a relative
> filename, the moved symlink will contain the same relative name, but by
> virtue of the fact that it lives in a different directory, it will (most
> likely) resolve to something different than what it referred to in the
> original location.
> 
> > 
> > Eric, it was only after I studied the man/info pages more carefully
> > regarding how mv should be executed (and other references) and how it
> > should behave that I checked the directory where it was and where I
> > expected it to go.
> > 
> > Here it is in the ns7 directory:
> > 
> > address@hidden ns7]$ ls
> > libjavaplugin_oji.so
> > 
> > Here is what the plugins directory looks like:
> > 
> > address@hidden plugins]$ ls
> > libgnashplugin.la  libgnashplugin.lai  libgnashplugin.so
> > libjavaplugin_oji.so
> 
> I asked for 'ls -l' so we could see full details, such as which files are
> symlinks.  According to your screenshot, you happen to have plain 'ls'
> aliased to a coloring version; with the four files on that line colored
> red, black, green, and blue (I'm guessing dangling symlink, regular file,
> symlink, executable); but rather than having to decode your colors, an 'ls
> -l' would have shown that unambiguously in black and white.
> 
> > 

Thanks for the explanation regarding the function of ls -l, quite instructive.
Note:  All directories are on the same disk.
Here is your request:

address@hidden ~]$ cd /opt/ibm/java*/jre/plugin/ppc/ns7
address@hidden ns7]$ ls -l
total 164
-rwxr-xr-x 1 root root 163244 Dec 14 23:39 libjavaplugin_oji.so
address@hidden ns7]$ cd /usr/lib/mozilla/plugins
address@hidden plugins]$ ls -l
total 52
lrwxrwxrwx 1 root   root      20 Dec 15 16:59 libgnashplugin.la
-> ../libgnashplugin.la -rw-r--r-- 1 root   root     869 Jan 24  2008
libgnashplugin.lai -rwxr-xr-x 1 root   root   45000 Jan 24  2008
libgnashplugin.so lrwxrwxrwx 1 aguila aguila    60 Jan 13 22:39
libjavaplugin_oji.so
-> /opt/ibm/java-ppc-60/jre/plugin/ppc/ns7/libjavaplugin_oji.so 
address@hidden plugins]$ 

As you can see libjavaplugin_oji.so in the ns7 directory is a shared object not
a symlink. What I reported earlier is accurate.  I originally executed mv in a
non-standard manner on this shared object file itself.
For me, developing an understanding mv's program logic as it executed a symbolic
link back to the shared object file would be worth pursuing.  

By the term, side effect, I mean unexpected/undocumented/ambiguous results
generated by malformed or unusual commands.  The command I executed to mv
was non-standard and produced the creation of a symbolic link which I've not
found referrenced as a standard function of mv.  I believe deducing the program
logic executed by mv as it followed the directive as I structured it, is worth
investigating.

Thanks to Eric, and all others on this list in helping me work through this
conundrum. 

Derick.


=========
Refranes/Popular sayings:
The Taino say:No hay mal que por bien no venga.
There is no evil out of which good cannot blossom.


=========
Refranes/Popular sayings:
The Taino say:No hay mal que por bien no venga.
There is no evil out of which good cannot blossom.

Attachment: signature.asc
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]