mv command is moving to the parent of the provided argument

The name of the pictureThe name of the pictureThe name of the pictureClash Royale CLAN TAG#URR8PPP











up vote
0
down vote

favorite












Let's say I have a working directory:



/home/userID/workingDirectory


I type a mv command that will affect the parent directory of the current working directory and the working directory itself:



mv .* /tmp/someDirectory


When executed, the command moves the content of both directories /home/userID and /home/userID/workingDirectory because .* is a match of the .. link in the current directory.



So far so good.



But, what I don't understand is why the files and directories are moved to the parent of the argument?



The files appear inside /tmp instead of /tmp/someDirectory



Can anybody throw some light?



OS is Solaris.



Thanks










share|improve this question

















  • 1




    Don't have solaris at hand so cannot verify, but you create all structure at the destination, so in particular move content of the parent directory ../* to /tmp/someDirectory/../* which is /tmp/*.
    – jimmij
    Sep 22 at 3:28











  • Ah, so. When mv goes to the destination path; it's using the argument to recreate the directory structure. And, as the argument to recreate the structure has itself a ../* then it's being interpreted as: /tmp/someDirectory/../* which will point to /tmp because is using the .. link inside /tmp/someDirectory. Am I correct?
    – Aeross
    Sep 22 at 3:58







  • 1




    I'm not sure about that interpretation. Can you verify the expansion of the glob with something like echo .* /tmp/someDirectory?
    – Sparhawk
    Sep 22 at 4:18










  • I have access to the servers until monday haha... Posted the question here at home because it was bothering me all the way here.
    – Aeross
    Sep 22 at 4:35














up vote
0
down vote

favorite












Let's say I have a working directory:



/home/userID/workingDirectory


I type a mv command that will affect the parent directory of the current working directory and the working directory itself:



mv .* /tmp/someDirectory


When executed, the command moves the content of both directories /home/userID and /home/userID/workingDirectory because .* is a match of the .. link in the current directory.



So far so good.



But, what I don't understand is why the files and directories are moved to the parent of the argument?



The files appear inside /tmp instead of /tmp/someDirectory



Can anybody throw some light?



OS is Solaris.



Thanks










share|improve this question

















  • 1




    Don't have solaris at hand so cannot verify, but you create all structure at the destination, so in particular move content of the parent directory ../* to /tmp/someDirectory/../* which is /tmp/*.
    – jimmij
    Sep 22 at 3:28











  • Ah, so. When mv goes to the destination path; it's using the argument to recreate the directory structure. And, as the argument to recreate the structure has itself a ../* then it's being interpreted as: /tmp/someDirectory/../* which will point to /tmp because is using the .. link inside /tmp/someDirectory. Am I correct?
    – Aeross
    Sep 22 at 3:58







  • 1




    I'm not sure about that interpretation. Can you verify the expansion of the glob with something like echo .* /tmp/someDirectory?
    – Sparhawk
    Sep 22 at 4:18










  • I have access to the servers until monday haha... Posted the question here at home because it was bothering me all the way here.
    – Aeross
    Sep 22 at 4:35












up vote
0
down vote

favorite









up vote
0
down vote

favorite











Let's say I have a working directory:



/home/userID/workingDirectory


I type a mv command that will affect the parent directory of the current working directory and the working directory itself:



mv .* /tmp/someDirectory


When executed, the command moves the content of both directories /home/userID and /home/userID/workingDirectory because .* is a match of the .. link in the current directory.



So far so good.



But, what I don't understand is why the files and directories are moved to the parent of the argument?



The files appear inside /tmp instead of /tmp/someDirectory



Can anybody throw some light?



OS is Solaris.



Thanks










share|improve this question













Let's say I have a working directory:



/home/userID/workingDirectory


I type a mv command that will affect the parent directory of the current working directory and the working directory itself:



mv .* /tmp/someDirectory


When executed, the command moves the content of both directories /home/userID and /home/userID/workingDirectory because .* is a match of the .. link in the current directory.



So far so good.



But, what I don't understand is why the files and directories are moved to the parent of the argument?



The files appear inside /tmp instead of /tmp/someDirectory



Can anybody throw some light?



OS is Solaris.



Thanks







command-line directory solaris mv






share|improve this question













share|improve this question











share|improve this question




share|improve this question










asked Sep 22 at 3:14









Aeross

1




1







  • 1




    Don't have solaris at hand so cannot verify, but you create all structure at the destination, so in particular move content of the parent directory ../* to /tmp/someDirectory/../* which is /tmp/*.
    – jimmij
    Sep 22 at 3:28











  • Ah, so. When mv goes to the destination path; it's using the argument to recreate the directory structure. And, as the argument to recreate the structure has itself a ../* then it's being interpreted as: /tmp/someDirectory/../* which will point to /tmp because is using the .. link inside /tmp/someDirectory. Am I correct?
    – Aeross
    Sep 22 at 3:58







  • 1




    I'm not sure about that interpretation. Can you verify the expansion of the glob with something like echo .* /tmp/someDirectory?
    – Sparhawk
    Sep 22 at 4:18










  • I have access to the servers until monday haha... Posted the question here at home because it was bothering me all the way here.
    – Aeross
    Sep 22 at 4:35












  • 1




    Don't have solaris at hand so cannot verify, but you create all structure at the destination, so in particular move content of the parent directory ../* to /tmp/someDirectory/../* which is /tmp/*.
    – jimmij
    Sep 22 at 3:28











  • Ah, so. When mv goes to the destination path; it's using the argument to recreate the directory structure. And, as the argument to recreate the structure has itself a ../* then it's being interpreted as: /tmp/someDirectory/../* which will point to /tmp because is using the .. link inside /tmp/someDirectory. Am I correct?
    – Aeross
    Sep 22 at 3:58







  • 1




    I'm not sure about that interpretation. Can you verify the expansion of the glob with something like echo .* /tmp/someDirectory?
    – Sparhawk
    Sep 22 at 4:18










  • I have access to the servers until monday haha... Posted the question here at home because it was bothering me all the way here.
    – Aeross
    Sep 22 at 4:35







1




1




Don't have solaris at hand so cannot verify, but you create all structure at the destination, so in particular move content of the parent directory ../* to /tmp/someDirectory/../* which is /tmp/*.
– jimmij
Sep 22 at 3:28





Don't have solaris at hand so cannot verify, but you create all structure at the destination, so in particular move content of the parent directory ../* to /tmp/someDirectory/../* which is /tmp/*.
– jimmij
Sep 22 at 3:28













Ah, so. When mv goes to the destination path; it's using the argument to recreate the directory structure. And, as the argument to recreate the structure has itself a ../* then it's being interpreted as: /tmp/someDirectory/../* which will point to /tmp because is using the .. link inside /tmp/someDirectory. Am I correct?
– Aeross
Sep 22 at 3:58





Ah, so. When mv goes to the destination path; it's using the argument to recreate the directory structure. And, as the argument to recreate the structure has itself a ../* then it's being interpreted as: /tmp/someDirectory/../* which will point to /tmp because is using the .. link inside /tmp/someDirectory. Am I correct?
– Aeross
Sep 22 at 3:58





1




1




I'm not sure about that interpretation. Can you verify the expansion of the glob with something like echo .* /tmp/someDirectory?
– Sparhawk
Sep 22 at 4:18




I'm not sure about that interpretation. Can you verify the expansion of the glob with something like echo .* /tmp/someDirectory?
– Sparhawk
Sep 22 at 4:18












I have access to the servers until monday haha... Posted the question here at home because it was bothering me all the way here.
– Aeross
Sep 22 at 4:35




I have access to the servers until monday haha... Posted the question here at home because it was bothering me all the way here.
– Aeross
Sep 22 at 4:35










1 Answer
1






active

oldest

votes

















up vote
2
down vote













Because basically the system is doing the following when using .*.

renameat(AT_FDCWD, "../workingDirectory", AT_FDCWD, "/tmp/narf/../workingDirectory") Err#18 EXDEV

Thus it's moved to /tmp/workingDirectory instead of /tmp/narf






share|improve this answer




















  • To be precise, given that the target is /tmp, the mv command probably first attempts your posted renameat() system call, which likely fails with errno set to EXDEV since /tmp is almost certainly on a different file system. The mv command will then copy the file(s), and if successful delete the original(s).
    – Andrew Henle
    Sep 23 at 22:21










  • Obviously. Otherwise it wouldn't throw the EXDEV. But it shows the directory string with the ".."
    – c0t0d0s0
    Sep 24 at 2:47










Your Answer







StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "106"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);

else
createEditor();

);

function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
convertImagesToLinks: false,
noModals: false,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);



);













 

draft saved


draft discarded


















StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f470653%2fmv-command-is-moving-to-the-parent-of-the-provided-argument%23new-answer', 'question_page');

);

Post as a guest






























1 Answer
1






active

oldest

votes








1 Answer
1






active

oldest

votes









active

oldest

votes






active

oldest

votes








up vote
2
down vote













Because basically the system is doing the following when using .*.

renameat(AT_FDCWD, "../workingDirectory", AT_FDCWD, "/tmp/narf/../workingDirectory") Err#18 EXDEV

Thus it's moved to /tmp/workingDirectory instead of /tmp/narf






share|improve this answer




















  • To be precise, given that the target is /tmp, the mv command probably first attempts your posted renameat() system call, which likely fails with errno set to EXDEV since /tmp is almost certainly on a different file system. The mv command will then copy the file(s), and if successful delete the original(s).
    – Andrew Henle
    Sep 23 at 22:21










  • Obviously. Otherwise it wouldn't throw the EXDEV. But it shows the directory string with the ".."
    – c0t0d0s0
    Sep 24 at 2:47














up vote
2
down vote













Because basically the system is doing the following when using .*.

renameat(AT_FDCWD, "../workingDirectory", AT_FDCWD, "/tmp/narf/../workingDirectory") Err#18 EXDEV

Thus it's moved to /tmp/workingDirectory instead of /tmp/narf






share|improve this answer




















  • To be precise, given that the target is /tmp, the mv command probably first attempts your posted renameat() system call, which likely fails with errno set to EXDEV since /tmp is almost certainly on a different file system. The mv command will then copy the file(s), and if successful delete the original(s).
    – Andrew Henle
    Sep 23 at 22:21










  • Obviously. Otherwise it wouldn't throw the EXDEV. But it shows the directory string with the ".."
    – c0t0d0s0
    Sep 24 at 2:47












up vote
2
down vote










up vote
2
down vote









Because basically the system is doing the following when using .*.

renameat(AT_FDCWD, "../workingDirectory", AT_FDCWD, "/tmp/narf/../workingDirectory") Err#18 EXDEV

Thus it's moved to /tmp/workingDirectory instead of /tmp/narf






share|improve this answer












Because basically the system is doing the following when using .*.

renameat(AT_FDCWD, "../workingDirectory", AT_FDCWD, "/tmp/narf/../workingDirectory") Err#18 EXDEV

Thus it's moved to /tmp/workingDirectory instead of /tmp/narf







share|improve this answer












share|improve this answer



share|improve this answer










answered Sep 22 at 21:22









c0t0d0s0

1262




1262











  • To be precise, given that the target is /tmp, the mv command probably first attempts your posted renameat() system call, which likely fails with errno set to EXDEV since /tmp is almost certainly on a different file system. The mv command will then copy the file(s), and if successful delete the original(s).
    – Andrew Henle
    Sep 23 at 22:21










  • Obviously. Otherwise it wouldn't throw the EXDEV. But it shows the directory string with the ".."
    – c0t0d0s0
    Sep 24 at 2:47
















  • To be precise, given that the target is /tmp, the mv command probably first attempts your posted renameat() system call, which likely fails with errno set to EXDEV since /tmp is almost certainly on a different file system. The mv command will then copy the file(s), and if successful delete the original(s).
    – Andrew Henle
    Sep 23 at 22:21










  • Obviously. Otherwise it wouldn't throw the EXDEV. But it shows the directory string with the ".."
    – c0t0d0s0
    Sep 24 at 2:47















To be precise, given that the target is /tmp, the mv command probably first attempts your posted renameat() system call, which likely fails with errno set to EXDEV since /tmp is almost certainly on a different file system. The mv command will then copy the file(s), and if successful delete the original(s).
– Andrew Henle
Sep 23 at 22:21




To be precise, given that the target is /tmp, the mv command probably first attempts your posted renameat() system call, which likely fails with errno set to EXDEV since /tmp is almost certainly on a different file system. The mv command will then copy the file(s), and if successful delete the original(s).
– Andrew Henle
Sep 23 at 22:21












Obviously. Otherwise it wouldn't throw the EXDEV. But it shows the directory string with the ".."
– c0t0d0s0
Sep 24 at 2:47




Obviously. Otherwise it wouldn't throw the EXDEV. But it shows the directory string with the ".."
– c0t0d0s0
Sep 24 at 2:47

















 

draft saved


draft discarded















































 


draft saved


draft discarded














StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f470653%2fmv-command-is-moving-to-the-parent-of-the-provided-argument%23new-answer', 'question_page');

);

Post as a guest













































































Popular posts from this blog

How to check contact read email or not when send email to Individual?

Displaying single band from multi-band raster using QGIS

How many registers does an x86_64 CPU actually have?