mv --dereference

Bonjour,

Question: "cp" has the option "-L, --dereference", does "mv" have a similar option? It seems not.

I only found a warning with [info '(coreutils) mv invocation'], and nothing in Linux-Newbie...

I plan to write a script to do this, I would have needed it this morning!
The question is funny, isn't it.

Kind regards,
Llyich

If you move a file referenced by a symlink you break this symlink, don't you?

In the case of cp -L it's supposedly dereferencing the source file. Perhaps in some cases cp may simply copy the link itself (although I just did some experimentation and it seems to always copy the source). The option -L enforces an actual copy of the file content itself, even if the source is a symlink.

If you use mv on a link, it simply moves the link itself. I suppose what the OP wants is to have mv not move the link itself, but instead create a new copy of the file and destroy the old link.

Basically,
would do the job.

1 members found this post helpful.

Bonjour, thank you for your answers.

"cp -L $1 $2 && rm -f $1", delete the links.
I had written "rml.py", I would have to adapt it and test it more thoroughly.

(I was organizing my personal data and wanted to do an mv instead of a cp to avoid duplicating data. To explain why I use links would be off topic here).

Kind regards,
--
Llyich

when copying files, both the original [symbolic] link and the [real] file remain in place (and you can decide if you want to copy the file or the link). move does not care about the type of the directory entry, it can be file, dir, link, whatever, that will be used (moved). If you wish to follow the link you need to implement it yourself, but it looks like you have already solved it.

1 members found this post helpful.

If avoiding duplication is what you want, consider hard links, or a filesystem that supports reflinks like xfs. I would hate to use symlinks for such a purpose as if you rename the target, you end up with a dangling symlink.

Bonjour, why I use links?

Here is a thunar action to quickly create links
I am grouping file links that can come from different HDs, and I delete them after use.

Uses:
I perform batch processing on the server, for example a switch to x265 codec.
The "source" stays on the HD 3.5".
The processing is faster than if it was done directly on the HD.
The server: Intel Quad Core I7 8550U, Samsung SSD Internal 970 EVO Plus NVMe M.2.

I also perform subtitle and audio extraction, using links on the files to be processed.

I do sorting, grouping, renaming of links, when it's files of the same HD, a "mv -L" would be faster than a "cp -rvL".

Kind regards,
--
Llyich

Hello Llyich,

I don't understand what you are doing.

Symlinks are good! I use them a lot. But why would you want to have "mv -L"? To move the link do this:

mv <link> <place>

To move the link target do this:

mv `readlink -f <link>` <place>

To reduce the amount of typing that you do, write script "mvtarg", give it execute permission, and put in in /usr/local/bin:

please use code tags if you want to post code.
Do not use backtick, but $( )
Do not use $*, but "$@"
I guess you wanted to use bash, not sh (see your shebang)
Also use shellcheck to check your script

1 members found this post helpful.

Hello pan64,

Thank you for taking an interest in my code and my post.

I did not know about the code tag, thank you!

Let me tell you about my code and about myself. First about myself. I am not a professional coder, but I have been coding long enough to have established a base of experience. Perhaps you are a professional coder?

You may not like my choices, but they were my choices. I will talk about them briefly so you and other readers will know what I did purposefully:

I like back tics and I used them on purpose. I have found that they work well for me, although I have occasionally used $(). I understand that the two are not equivalent, although I cannot tell you off hand how they are different. Perhaps I have something about that in my notes.

The story regarding my use of $* instead of $@ is similar, although I know a little more about the differences in this case. I have in my notes an example of the use of $@, and I do use this in code when I want to pass arguments that contain spaces from one invocation to another. (I hope I said that right--I can give you an example if you like.)

My post contained this shebang: #!/bin/sh. Did you miss it?

I think my spelling is pretty good. Bear in my mind the possibility of regional differences in spelling, however if you think I misspelled a word, or made other errors of presentation, please let me know.

So that is the story about my code and myself. Thank you for your comments.

-Joe

I've no idea why Pan64 wrote "I guess you wanted to use bash, not sh (see your shebang)" - there's no Bash-specific syntax there, so no benefit in requiring Bash.

For the difference between command substitution syntax, see BashFAQ #82 Why is $(...) preferred over `...` (backticks)?

On the passing arguments bit, you should be using '"$@"' not '$*' - see SC2048 Use "$@" (with quotes) to prevent whitespace problems for an example of why.

ShellCheck is useful for highlighting these issues - it's both a website and an offline tool, and BashFAQ/BashPitfalls are both useful references. (Not everything in them is Bash-specific.)

1 members found this post helpful.

Hello pan64,

I made two mistakes when reading your post. I thought you wrote that I had not included a shebang. On re-reading I see that you questioned why I used sh instead of bash. The answer is that I wanted to use sh--I used it on purpose. In Slackware /bin/sh is a symlink to bash, although I believe that the use of #!/bin/sh is not equivalent to the use of #!/bin/bash.

My other mistake was that I thought you were recommending that I use a spell-checker. Ha! I was groggy from a good night's sleep when I responded. About shell-checkers and other such tools, I don't use them, as I don't find them to be helpful. I understand why these tools abound. Businesses need standards to keep odd coding techniques from creeping in to the code base. I code for myself and for those who wish to use my code, not for an employer.

Forgive me for these clumsy errors!

-Joe

Hello boughtonp,

Regarding the back tic, the site you referenced seems to say it is a matter of preference. It describes inconveniences associated with the use of the back tic. Certainly it does not say that one cannot successfully use the back tic. I use it when I can, which is most of the time, because I like it.

Regarding the use of "$@" (with quotes), I don't believe it is wrong to use $*. The error happens in the use of the script, not in the writing of the script. If the user wishes to pass arguments containing spaces--I think this is the matter in question--then yes he should write a script in the way that you recommend. Otherwise it doesn't matter, yes? As a kindness to others, perhaps it would have been better to have written it as you suggested.

Thanks, by the way, for your several references to interesting web articles/sites about coding.

-Joe

It's a bug in the script - it incorrectly splits quoted arguments.

This is funny. I looked it up and learned that the correct spelling is "backtick". Back tic is something else altogether. See involuntary twitch.

-Joe