Multiple symlinks by wildcard: âln -s ../*/*.txt TXT/â
Clash Royale CLAN TAG#URR8PPP
up vote
1
down vote
favorite
I'm trying to create multiple symbolic links using wildcard, here the example:
$ ls -R
.:
TXT a b
./TXT:
./a:
a.txt
./b:
b.txt
There is a "parent directoory" containing various subdirs: a, b, TXT.
In "a" and "b" there are various text files (a.txt, b.txt in the above
example).
I want to create "relative" symbolic links to each ".txt" files whitin the "TXT"
subdir.
But:
- without using "find"
- without "cd" in TXT directory
In other words I want to know why a command like the following doesn't
work:
ln -s ../*/*txt TXT/
With a previus "cd TXT" it works:
cd TXT
ln -s ../*/*txt .
I think the issue appears due to bash expansion of "*" and "../", bash is not able to expand "../*/*.txt" because those files actually don't exist, so "ln" cannot create the desired links:
it creates links to txt files of "one level up" dirs relative to the current workdir. It "cd" to ".." and considers all dirs at this level, looking for the ".txt" files within these.
Maybe "the rule" could be symlink TARGET has to:
- point at the same time at real existing files (otherwise bash can't expand ".." or "*" in the right way)
- and it has to be relative to the DIRECTORY that will contain the link
Could you confirm and explain what exactly is the problem and possible solutions?
PS.
Using "find", a command like the following seems to work:
find ./ -path ./TXT -prune -o -iname "*.txt" -type f -exec ln -s ."" -t TXT/ ;
Note that even in this case I have to use a "non existing" path:
.""
But the -exec command just expands "" which is "./a/a.txt" and "./b/b.txt", so "ln" can build the right path relative to TXT destdir thanks to the prefixed dot ".".
wildcards ln
add a comment |Â
up vote
1
down vote
favorite
I'm trying to create multiple symbolic links using wildcard, here the example:
$ ls -R
.:
TXT a b
./TXT:
./a:
a.txt
./b:
b.txt
There is a "parent directoory" containing various subdirs: a, b, TXT.
In "a" and "b" there are various text files (a.txt, b.txt in the above
example).
I want to create "relative" symbolic links to each ".txt" files whitin the "TXT"
subdir.
But:
- without using "find"
- without "cd" in TXT directory
In other words I want to know why a command like the following doesn't
work:
ln -s ../*/*txt TXT/
With a previus "cd TXT" it works:
cd TXT
ln -s ../*/*txt .
I think the issue appears due to bash expansion of "*" and "../", bash is not able to expand "../*/*.txt" because those files actually don't exist, so "ln" cannot create the desired links:
it creates links to txt files of "one level up" dirs relative to the current workdir. It "cd" to ".." and considers all dirs at this level, looking for the ".txt" files within these.
Maybe "the rule" could be symlink TARGET has to:
- point at the same time at real existing files (otherwise bash can't expand ".." or "*" in the right way)
- and it has to be relative to the DIRECTORY that will contain the link
Could you confirm and explain what exactly is the problem and possible solutions?
PS.
Using "find", a command like the following seems to work:
find ./ -path ./TXT -prune -o -iname "*.txt" -type f -exec ln -s ."" -t TXT/ ;
Note that even in this case I have to use a "non existing" path:
.""
But the -exec command just expands "" which is "./a/a.txt" and "./b/b.txt", so "ln" can build the right path relative to TXT destdir thanks to the prefixed dot ".".
wildcards ln
Possible duplicate of Create symbolic links with wildcards
â Romeo Ninov
Dec 14 '17 at 10:19
@RomeoNinov not a duplicate. Your suggested question uses absolute symlinks. The question here is about the relative symbolic links not working
â roaima
Dec 14 '17 at 12:25
@roaima, the wildcard mechanism in shell is the same, independently of the type of symlink
â Romeo Ninov
Dec 14 '17 at 12:28
@RomeoNinov I don't see any answer there that is applicable to the problem described here
â roaima
Dec 14 '17 at 12:32
add a comment |Â
up vote
1
down vote
favorite
up vote
1
down vote
favorite
I'm trying to create multiple symbolic links using wildcard, here the example:
$ ls -R
.:
TXT a b
./TXT:
./a:
a.txt
./b:
b.txt
There is a "parent directoory" containing various subdirs: a, b, TXT.
In "a" and "b" there are various text files (a.txt, b.txt in the above
example).
I want to create "relative" symbolic links to each ".txt" files whitin the "TXT"
subdir.
But:
- without using "find"
- without "cd" in TXT directory
In other words I want to know why a command like the following doesn't
work:
ln -s ../*/*txt TXT/
With a previus "cd TXT" it works:
cd TXT
ln -s ../*/*txt .
I think the issue appears due to bash expansion of "*" and "../", bash is not able to expand "../*/*.txt" because those files actually don't exist, so "ln" cannot create the desired links:
it creates links to txt files of "one level up" dirs relative to the current workdir. It "cd" to ".." and considers all dirs at this level, looking for the ".txt" files within these.
Maybe "the rule" could be symlink TARGET has to:
- point at the same time at real existing files (otherwise bash can't expand ".." or "*" in the right way)
- and it has to be relative to the DIRECTORY that will contain the link
Could you confirm and explain what exactly is the problem and possible solutions?
PS.
Using "find", a command like the following seems to work:
find ./ -path ./TXT -prune -o -iname "*.txt" -type f -exec ln -s ."" -t TXT/ ;
Note that even in this case I have to use a "non existing" path:
.""
But the -exec command just expands "" which is "./a/a.txt" and "./b/b.txt", so "ln" can build the right path relative to TXT destdir thanks to the prefixed dot ".".
wildcards ln
I'm trying to create multiple symbolic links using wildcard, here the example:
$ ls -R
.:
TXT a b
./TXT:
./a:
a.txt
./b:
b.txt
There is a "parent directoory" containing various subdirs: a, b, TXT.
In "a" and "b" there are various text files (a.txt, b.txt in the above
example).
I want to create "relative" symbolic links to each ".txt" files whitin the "TXT"
subdir.
But:
- without using "find"
- without "cd" in TXT directory
In other words I want to know why a command like the following doesn't
work:
ln -s ../*/*txt TXT/
With a previus "cd TXT" it works:
cd TXT
ln -s ../*/*txt .
I think the issue appears due to bash expansion of "*" and "../", bash is not able to expand "../*/*.txt" because those files actually don't exist, so "ln" cannot create the desired links:
it creates links to txt files of "one level up" dirs relative to the current workdir. It "cd" to ".." and considers all dirs at this level, looking for the ".txt" files within these.
Maybe "the rule" could be symlink TARGET has to:
- point at the same time at real existing files (otherwise bash can't expand ".." or "*" in the right way)
- and it has to be relative to the DIRECTORY that will contain the link
Could you confirm and explain what exactly is the problem and possible solutions?
PS.
Using "find", a command like the following seems to work:
find ./ -path ./TXT -prune -o -iname "*.txt" -type f -exec ln -s ."" -t TXT/ ;
Note that even in this case I have to use a "non existing" path:
.""
But the -exec command just expands "" which is "./a/a.txt" and "./b/b.txt", so "ln" can build the right path relative to TXT destdir thanks to the prefixed dot ".".
wildcards ln
asked Dec 14 '17 at 10:06
Joe
264
264
Possible duplicate of Create symbolic links with wildcards
â Romeo Ninov
Dec 14 '17 at 10:19
@RomeoNinov not a duplicate. Your suggested question uses absolute symlinks. The question here is about the relative symbolic links not working
â roaima
Dec 14 '17 at 12:25
@roaima, the wildcard mechanism in shell is the same, independently of the type of symlink
â Romeo Ninov
Dec 14 '17 at 12:28
@RomeoNinov I don't see any answer there that is applicable to the problem described here
â roaima
Dec 14 '17 at 12:32
add a comment |Â
Possible duplicate of Create symbolic links with wildcards
â Romeo Ninov
Dec 14 '17 at 10:19
@RomeoNinov not a duplicate. Your suggested question uses absolute symlinks. The question here is about the relative symbolic links not working
â roaima
Dec 14 '17 at 12:25
@roaima, the wildcard mechanism in shell is the same, independently of the type of symlink
â Romeo Ninov
Dec 14 '17 at 12:28
@RomeoNinov I don't see any answer there that is applicable to the problem described here
â roaima
Dec 14 '17 at 12:32
Possible duplicate of Create symbolic links with wildcards
â Romeo Ninov
Dec 14 '17 at 10:19
Possible duplicate of Create symbolic links with wildcards
â Romeo Ninov
Dec 14 '17 at 10:19
@RomeoNinov not a duplicate. Your suggested question uses absolute symlinks. The question here is about the relative symbolic links not working
â roaima
Dec 14 '17 at 12:25
@RomeoNinov not a duplicate. Your suggested question uses absolute symlinks. The question here is about the relative symbolic links not working
â roaima
Dec 14 '17 at 12:25
@roaima, the wildcard mechanism in shell is the same, independently of the type of symlink
â Romeo Ninov
Dec 14 '17 at 12:28
@roaima, the wildcard mechanism in shell is the same, independently of the type of symlink
â Romeo Ninov
Dec 14 '17 at 12:28
@RomeoNinov I don't see any answer there that is applicable to the problem described here
â roaima
Dec 14 '17 at 12:32
@RomeoNinov I don't see any answer there that is applicable to the problem described here
â roaima
Dec 14 '17 at 12:32
add a comment |Â
1 Answer
1
active
oldest
votes
up vote
2
down vote
You're using this command
ln -s ../*/*txt TXT/
If you are in the directory containing a
, b
, and TXT
then the shell will fail to expand ../*/*txt
to match anything in a
or b
. You would have to use */*txt
for that, but then the symbolic links inside TXT
would be off by one level and they would need another ../
in their relative paths.
The easiest solution would be this, but you say you want to avoid cd
( cd TXT && ln -s ../*/*txt . )
Another solution would require fixing up the links in turn
for f in */*txt
do
ln -s ../"$f" TXT
done
Be aware that because you have your source directories a
and b
at the same level as TXT
, the wildcards in both of the suggestions will match all three directories.
for f in [a-z]*/*txt
should solve in my case: I can name the files subdir (a, b in the example) as I prefer: I can choose names beginning in lowercase letter [a-z] and target dir TXT in caps.
â Joe
Dec 14 '17 at 13:22
The problem could poup up if a source subdir doesn't contain any *.txt file. In that case will be created an unwanted broken link in TXT named*.txt
. This problem occurs also with thecd
solution... That is the usual behavior ofln
command, anyway should be better to create the link just in case the linked file really exists...
â Joe
Dec 14 '17 at 13:23
1
@Joe be very careful with your locale if you're expecting[a-z]
to miss your uppercaseTXT
directory. Check withecho [a-z]*
.
â roaima
Dec 14 '17 at 16:30
@Joeln -s
will create a symbolic link to anything, whether or not it exists. This isn't really "unusual behaviour", but you might prefer in this instance thatln -s
didn't do that.
â roaima
Dec 14 '17 at 16:33
Yes indeed I'm using my above reported version based on "find".find
command automatically filters just the existing files. Moreover it allow to refine the selection of the files which to create the links to (based on certain pattern in their name for example). And it allow subdir exclusion too, by the"-path $DIRTOEXCLUDE -prune"
. Anyway I asked just to understand the wildcard behavior along the symlink command ln. A remark: with hardlink there isn't any problem... but hard link and symlink are not the same... Thank you for suggests! :)
â Joe
Dec 14 '17 at 17:12
add a comment |Â
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
2
down vote
You're using this command
ln -s ../*/*txt TXT/
If you are in the directory containing a
, b
, and TXT
then the shell will fail to expand ../*/*txt
to match anything in a
or b
. You would have to use */*txt
for that, but then the symbolic links inside TXT
would be off by one level and they would need another ../
in their relative paths.
The easiest solution would be this, but you say you want to avoid cd
( cd TXT && ln -s ../*/*txt . )
Another solution would require fixing up the links in turn
for f in */*txt
do
ln -s ../"$f" TXT
done
Be aware that because you have your source directories a
and b
at the same level as TXT
, the wildcards in both of the suggestions will match all three directories.
for f in [a-z]*/*txt
should solve in my case: I can name the files subdir (a, b in the example) as I prefer: I can choose names beginning in lowercase letter [a-z] and target dir TXT in caps.
â Joe
Dec 14 '17 at 13:22
The problem could poup up if a source subdir doesn't contain any *.txt file. In that case will be created an unwanted broken link in TXT named*.txt
. This problem occurs also with thecd
solution... That is the usual behavior ofln
command, anyway should be better to create the link just in case the linked file really exists...
â Joe
Dec 14 '17 at 13:23
1
@Joe be very careful with your locale if you're expecting[a-z]
to miss your uppercaseTXT
directory. Check withecho [a-z]*
.
â roaima
Dec 14 '17 at 16:30
@Joeln -s
will create a symbolic link to anything, whether or not it exists. This isn't really "unusual behaviour", but you might prefer in this instance thatln -s
didn't do that.
â roaima
Dec 14 '17 at 16:33
Yes indeed I'm using my above reported version based on "find".find
command automatically filters just the existing files. Moreover it allow to refine the selection of the files which to create the links to (based on certain pattern in their name for example). And it allow subdir exclusion too, by the"-path $DIRTOEXCLUDE -prune"
. Anyway I asked just to understand the wildcard behavior along the symlink command ln. A remark: with hardlink there isn't any problem... but hard link and symlink are not the same... Thank you for suggests! :)
â Joe
Dec 14 '17 at 17:12
add a comment |Â
up vote
2
down vote
You're using this command
ln -s ../*/*txt TXT/
If you are in the directory containing a
, b
, and TXT
then the shell will fail to expand ../*/*txt
to match anything in a
or b
. You would have to use */*txt
for that, but then the symbolic links inside TXT
would be off by one level and they would need another ../
in their relative paths.
The easiest solution would be this, but you say you want to avoid cd
( cd TXT && ln -s ../*/*txt . )
Another solution would require fixing up the links in turn
for f in */*txt
do
ln -s ../"$f" TXT
done
Be aware that because you have your source directories a
and b
at the same level as TXT
, the wildcards in both of the suggestions will match all three directories.
for f in [a-z]*/*txt
should solve in my case: I can name the files subdir (a, b in the example) as I prefer: I can choose names beginning in lowercase letter [a-z] and target dir TXT in caps.
â Joe
Dec 14 '17 at 13:22
The problem could poup up if a source subdir doesn't contain any *.txt file. In that case will be created an unwanted broken link in TXT named*.txt
. This problem occurs also with thecd
solution... That is the usual behavior ofln
command, anyway should be better to create the link just in case the linked file really exists...
â Joe
Dec 14 '17 at 13:23
1
@Joe be very careful with your locale if you're expecting[a-z]
to miss your uppercaseTXT
directory. Check withecho [a-z]*
.
â roaima
Dec 14 '17 at 16:30
@Joeln -s
will create a symbolic link to anything, whether or not it exists. This isn't really "unusual behaviour", but you might prefer in this instance thatln -s
didn't do that.
â roaima
Dec 14 '17 at 16:33
Yes indeed I'm using my above reported version based on "find".find
command automatically filters just the existing files. Moreover it allow to refine the selection of the files which to create the links to (based on certain pattern in their name for example). And it allow subdir exclusion too, by the"-path $DIRTOEXCLUDE -prune"
. Anyway I asked just to understand the wildcard behavior along the symlink command ln. A remark: with hardlink there isn't any problem... but hard link and symlink are not the same... Thank you for suggests! :)
â Joe
Dec 14 '17 at 17:12
add a comment |Â
up vote
2
down vote
up vote
2
down vote
You're using this command
ln -s ../*/*txt TXT/
If you are in the directory containing a
, b
, and TXT
then the shell will fail to expand ../*/*txt
to match anything in a
or b
. You would have to use */*txt
for that, but then the symbolic links inside TXT
would be off by one level and they would need another ../
in their relative paths.
The easiest solution would be this, but you say you want to avoid cd
( cd TXT && ln -s ../*/*txt . )
Another solution would require fixing up the links in turn
for f in */*txt
do
ln -s ../"$f" TXT
done
Be aware that because you have your source directories a
and b
at the same level as TXT
, the wildcards in both of the suggestions will match all three directories.
You're using this command
ln -s ../*/*txt TXT/
If you are in the directory containing a
, b
, and TXT
then the shell will fail to expand ../*/*txt
to match anything in a
or b
. You would have to use */*txt
for that, but then the symbolic links inside TXT
would be off by one level and they would need another ../
in their relative paths.
The easiest solution would be this, but you say you want to avoid cd
( cd TXT && ln -s ../*/*txt . )
Another solution would require fixing up the links in turn
for f in */*txt
do
ln -s ../"$f" TXT
done
Be aware that because you have your source directories a
and b
at the same level as TXT
, the wildcards in both of the suggestions will match all three directories.
answered Dec 14 '17 at 12:36
roaima
39.8k546109
39.8k546109
for f in [a-z]*/*txt
should solve in my case: I can name the files subdir (a, b in the example) as I prefer: I can choose names beginning in lowercase letter [a-z] and target dir TXT in caps.
â Joe
Dec 14 '17 at 13:22
The problem could poup up if a source subdir doesn't contain any *.txt file. In that case will be created an unwanted broken link in TXT named*.txt
. This problem occurs also with thecd
solution... That is the usual behavior ofln
command, anyway should be better to create the link just in case the linked file really exists...
â Joe
Dec 14 '17 at 13:23
1
@Joe be very careful with your locale if you're expecting[a-z]
to miss your uppercaseTXT
directory. Check withecho [a-z]*
.
â roaima
Dec 14 '17 at 16:30
@Joeln -s
will create a symbolic link to anything, whether or not it exists. This isn't really "unusual behaviour", but you might prefer in this instance thatln -s
didn't do that.
â roaima
Dec 14 '17 at 16:33
Yes indeed I'm using my above reported version based on "find".find
command automatically filters just the existing files. Moreover it allow to refine the selection of the files which to create the links to (based on certain pattern in their name for example). And it allow subdir exclusion too, by the"-path $DIRTOEXCLUDE -prune"
. Anyway I asked just to understand the wildcard behavior along the symlink command ln. A remark: with hardlink there isn't any problem... but hard link and symlink are not the same... Thank you for suggests! :)
â Joe
Dec 14 '17 at 17:12
add a comment |Â
for f in [a-z]*/*txt
should solve in my case: I can name the files subdir (a, b in the example) as I prefer: I can choose names beginning in lowercase letter [a-z] and target dir TXT in caps.
â Joe
Dec 14 '17 at 13:22
The problem could poup up if a source subdir doesn't contain any *.txt file. In that case will be created an unwanted broken link in TXT named*.txt
. This problem occurs also with thecd
solution... That is the usual behavior ofln
command, anyway should be better to create the link just in case the linked file really exists...
â Joe
Dec 14 '17 at 13:23
1
@Joe be very careful with your locale if you're expecting[a-z]
to miss your uppercaseTXT
directory. Check withecho [a-z]*
.
â roaima
Dec 14 '17 at 16:30
@Joeln -s
will create a symbolic link to anything, whether or not it exists. This isn't really "unusual behaviour", but you might prefer in this instance thatln -s
didn't do that.
â roaima
Dec 14 '17 at 16:33
Yes indeed I'm using my above reported version based on "find".find
command automatically filters just the existing files. Moreover it allow to refine the selection of the files which to create the links to (based on certain pattern in their name for example). And it allow subdir exclusion too, by the"-path $DIRTOEXCLUDE -prune"
. Anyway I asked just to understand the wildcard behavior along the symlink command ln. A remark: with hardlink there isn't any problem... but hard link and symlink are not the same... Thank you for suggests! :)
â Joe
Dec 14 '17 at 17:12
for f in [a-z]*/*txt
should solve in my case: I can name the files subdir (a, b in the example) as I prefer: I can choose names beginning in lowercase letter [a-z] and target dir TXT in caps.â Joe
Dec 14 '17 at 13:22
for f in [a-z]*/*txt
should solve in my case: I can name the files subdir (a, b in the example) as I prefer: I can choose names beginning in lowercase letter [a-z] and target dir TXT in caps.â Joe
Dec 14 '17 at 13:22
The problem could poup up if a source subdir doesn't contain any *.txt file. In that case will be created an unwanted broken link in TXT named
*.txt
. This problem occurs also with the cd
solution... That is the usual behavior of ln
command, anyway should be better to create the link just in case the linked file really exists...â Joe
Dec 14 '17 at 13:23
The problem could poup up if a source subdir doesn't contain any *.txt file. In that case will be created an unwanted broken link in TXT named
*.txt
. This problem occurs also with the cd
solution... That is the usual behavior of ln
command, anyway should be better to create the link just in case the linked file really exists...â Joe
Dec 14 '17 at 13:23
1
1
@Joe be very careful with your locale if you're expecting
[a-z]
to miss your uppercase TXT
directory. Check with echo [a-z]*
.â roaima
Dec 14 '17 at 16:30
@Joe be very careful with your locale if you're expecting
[a-z]
to miss your uppercase TXT
directory. Check with echo [a-z]*
.â roaima
Dec 14 '17 at 16:30
@Joe
ln -s
will create a symbolic link to anything, whether or not it exists. This isn't really "unusual behaviour", but you might prefer in this instance that ln -s
didn't do that.â roaima
Dec 14 '17 at 16:33
@Joe
ln -s
will create a symbolic link to anything, whether or not it exists. This isn't really "unusual behaviour", but you might prefer in this instance that ln -s
didn't do that.â roaima
Dec 14 '17 at 16:33
Yes indeed I'm using my above reported version based on "find".
find
command automatically filters just the existing files. Moreover it allow to refine the selection of the files which to create the links to (based on certain pattern in their name for example). And it allow subdir exclusion too, by the "-path $DIRTOEXCLUDE -prune"
. Anyway I asked just to understand the wildcard behavior along the symlink command ln. A remark: with hardlink there isn't any problem... but hard link and symlink are not the same... Thank you for suggests! :)â Joe
Dec 14 '17 at 17:12
Yes indeed I'm using my above reported version based on "find".
find
command automatically filters just the existing files. Moreover it allow to refine the selection of the files which to create the links to (based on certain pattern in their name for example). And it allow subdir exclusion too, by the "-path $DIRTOEXCLUDE -prune"
. Anyway I asked just to understand the wildcard behavior along the symlink command ln. A remark: with hardlink there isn't any problem... but hard link and symlink are not the same... Thank you for suggests! :)â Joe
Dec 14 '17 at 17:12
add a comment |Â
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f410834%2fmultiple-symlinks-by-wildcard-ln-s-txt-txt%23new-answer', 'question_page');
);
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Possible duplicate of Create symbolic links with wildcards
â Romeo Ninov
Dec 14 '17 at 10:19
@RomeoNinov not a duplicate. Your suggested question uses absolute symlinks. The question here is about the relative symbolic links not working
â roaima
Dec 14 '17 at 12:25
@roaima, the wildcard mechanism in shell is the same, independently of the type of symlink
â Romeo Ninov
Dec 14 '17 at 12:28
@RomeoNinov I don't see any answer there that is applicable to the problem described here
â roaima
Dec 14 '17 at 12:32