How do I disable the 'open' command, knowing that it is just a link to the 'openvt' binary?
Clash Royale CLAN TAG#URR8PPP up vote
4
down vote
favorite
I'd like users to be able to install my command line tool...
https://github.com/occam-proof-assistant/Open-CLI
...globally and run it from the terminal by typing open. The NodeJS package manager, npm, provides this facility, creating the necessary symbolic link when you install packages globally. So in the /usr/bin directory, I see the following symbolic link has indeed been created:
open -> ../lib/node_modules/occam-open-cli/open.js
However, this only works if I'm root, otherwise I get:
Couldn't get a file descriptor referring to the console
I know what this is, sort of. If I type openvt, I get the same message.
So I need to be able to delete the alias, or whatever, that allows openvt to be invoked with open. I think this is a safe thing to do, since you can always just fall back to typing openvt if you want to.
However, I'm at a loss to find a way to do this. I'd assumed that there was some kind of alias, but typing unalias open didn't work.
So what/where is this mystery open command, alias, symbolic link or whatever? And how can I safely remove it, and advise others to do the same?
command-line symbolic-link alias
asked Mar 22 at 17:27
James Smith
1618
 |Â
show 2 more comments
up vote
4
down vote
favorite
I'd like users to be able to install my command line tool...
https://github.com/occam-proof-assistant/Open-CLI
...globally and run it from the terminal by typing open. The NodeJS package manager, npm, provides this facility, creating the necessary symbolic link when you install packages globally. So in the /usr/bin directory, I see the following symbolic link has indeed been created:
open -> ../lib/node_modules/occam-open-cli/open.js
However, this only works if I'm root, otherwise I get:
Couldn't get a file descriptor referring to the console
I know what this is, sort of. If I type openvt, I get the same message.
So I need to be able to delete the alias, or whatever, that allows openvt to be invoked with open. I think this is a safe thing to do, since you can always just fall back to typing openvt if you want to.
However, I'm at a loss to find a way to do this. I'd assumed that there was some kind of alias, but typing unalias open didn't work.
So what/where is this mystery open command, alias, symbolic link or whatever? And how can I safely remove it, and advise others to do the same?
command-line symbolic-link alias
asked Mar 22 at 17:27
James Smith
1618
3
I might be misreading your question, but if you typetype -a open, it should show you all the things thatopenmeans to the shell
– Zanna
Mar 22 at 17:29
Thanks. I tried it. I get/usr/bin/openand/bin/open. I'll investigate what this are, whether links or binaries...
– James Smith
Mar 22 at 17:36
17
Just as a suggestion, maybe you should try avoiding using such a generic name for your tool. The fact that you are deleting symlinks that are default on your system already means that someone used to using such a symlink that installs your product is going to see some frustrations. Let alone the fact that someone else may come up with another utility and want to use simplyopenas the command as well.
– Brian Sizemore
Mar 22 at 18:22
2
Those symlinks are installed by the system package manager, you potentially just broke your users system. Manually deleting symlinks is not a solution I would accept for a program unless it was very early development and I was participating.
– crasic
Mar 22 at 20:18
1
@BrianSizemore and @crasic are right. You're asking for trouble using a name that's so generic. There's a pretty high likelihood of users having an alias or shell function namedopenthat wraps commonly-used commands. As like @Zanna said, aliases will always take precedence over other commands.
– Alhadis
Mar 23 at 4:07
 |Â
show 2 more comments
up vote
4
down vote
favorite
up vote
4
down vote
favorite
I'd like users to be able to install my command line tool...
https://github.com/occam-proof-assistant/Open-CLI
...globally and run it from the terminal by typing open. The NodeJS package manager, npm, provides this facility, creating the necessary symbolic link when you install packages globally. So in the /usr/bin directory, I see the following symbolic link has indeed been created:
open -> ../lib/node_modules/occam-open-cli/open.js
However, this only works if I'm root, otherwise I get:
Couldn't get a file descriptor referring to the console
I know what this is, sort of. If I type openvt, I get the same message.
So I need to be able to delete the alias, or whatever, that allows openvt to be invoked with open. I think this is a safe thing to do, since you can always just fall back to typing openvt if you want to.
However, I'm at a loss to find a way to do this. I'd assumed that there was some kind of alias, but typing unalias open didn't work.
So what/where is this mystery open command, alias, symbolic link or whatever? And how can I safely remove it, and advise others to do the same?
command-line symbolic-link alias
asked Mar 22 at 17:27
James Smith
1618
I'd like users to be able to install my command line tool...
https://github.com/occam-proof-assistant/Open-CLI
...globally and run it from the terminal by typing open. The NodeJS package manager, npm, provides this facility, creating the necessary symbolic link when you install packages globally. So in the /usr/bin directory, I see the following symbolic link has indeed been created:
open -> ../lib/node_modules/occam-open-cli/open.js
However, this only works if I'm root, otherwise I get:
Couldn't get a file descriptor referring to the console
I know what this is, sort of. If I type openvt, I get the same message.
So I need to be able to delete the alias, or whatever, that allows openvt to be invoked with open. I think this is a safe thing to do, since you can always just fall back to typing openvt if you want to.
However, I'm at a loss to find a way to do this. I'd assumed that there was some kind of alias, but typing unalias open didn't work.
So what/where is this mystery open command, alias, symbolic link or whatever? And how can I safely remove it, and advise others to do the same?
command-line symbolic-link alias
command-line symbolic-link alias
asked Mar 22 at 17:27
James Smith
1618
asked Mar 22 at 17:27
James Smith
1618
asked Mar 22 at 17:27
James Smith
1618
asked Mar 22 at 17:27
James Smith
1618
asked Mar 22 at 17:27
James Smith
1618
1618
3
I might be misreading your question, but if you typetype -a open, it should show you all the things thatopenmeans to the shell
– Zanna
Mar 22 at 17:29
Thanks. I tried it. I get/usr/bin/openand/bin/open. I'll investigate what this are, whether links or binaries...
– James Smith
Mar 22 at 17:36
17
Just as a suggestion, maybe you should try avoiding using such a generic name for your tool. The fact that you are deleting symlinks that are default on your system already means that someone used to using such a symlink that installs your product is going to see some frustrations. Let alone the fact that someone else may come up with another utility and want to use simplyopenas the command as well.
– Brian Sizemore
Mar 22 at 18:22
2
Those symlinks are installed by the system package manager, you potentially just broke your users system. Manually deleting symlinks is not a solution I would accept for a program unless it was very early development and I was participating.
– crasic
Mar 22 at 20:18
1
@BrianSizemore and @crasic are right. You're asking for trouble using a name that's so generic. There's a pretty high likelihood of users having an alias or shell function namedopenthat wraps commonly-used commands. As like @Zanna said, aliases will always take precedence over other commands.
– Alhadis
Mar 23 at 4:07
 |Â
show 2 more comments
3
I might be misreading your question, but if you typetype -a open, it should show you all the things thatopenmeans to the shell
– Zanna
Mar 22 at 17:29
Thanks. I tried it. I get/usr/bin/openand/bin/open. I'll investigate what this are, whether links or binaries...
– James Smith
Mar 22 at 17:36
17
Just as a suggestion, maybe you should try avoiding using such a generic name for your tool. The fact that you are deleting symlinks that are default on your system already means that someone used to using such a symlink that installs your product is going to see some frustrations. Let alone the fact that someone else may come up with another utility and want to use simplyopenas the command as well.
– Brian Sizemore
Mar 22 at 18:22
2
Those symlinks are installed by the system package manager, you potentially just broke your users system. Manually deleting symlinks is not a solution I would accept for a program unless it was very early development and I was participating.
– crasic
Mar 22 at 20:18
1
@BrianSizemore and @crasic are right. You're asking for trouble using a name that's so generic. There's a pretty high likelihood of users having an alias or shell function namedopenthat wraps commonly-used commands. As like @Zanna said, aliases will always take precedence over other commands.
– Alhadis
Mar 23 at 4:07
3
3
I might be misreading your question, but if you type
type -a open, it should show you all the things that open means to the shell– Zanna
Mar 22 at 17:29
I might be misreading your question, but if you type
type -a open, it should show you all the things that open means to the shell– Zanna
Mar 22 at 17:29
Thanks. I tried it. I get
/usr/bin/open and /bin/open. I'll investigate what this are, whether links or binaries...– James Smith
Mar 22 at 17:36
Thanks. I tried it. I get
/usr/bin/open and /bin/open. I'll investigate what this are, whether links or binaries...– James Smith
Mar 22 at 17:36
17
17
Just as a suggestion, maybe you should try avoiding using such a generic name for your tool. The fact that you are deleting symlinks that are default on your system already means that someone used to using such a symlink that installs your product is going to see some frustrations. Let alone the fact that someone else may come up with another utility and want to use simply
open as the command as well.– Brian Sizemore
Mar 22 at 18:22
Just as a suggestion, maybe you should try avoiding using such a generic name for your tool. The fact that you are deleting symlinks that are default on your system already means that someone used to using such a symlink that installs your product is going to see some frustrations. Let alone the fact that someone else may come up with another utility and want to use simply
open as the command as well.– Brian Sizemore
Mar 22 at 18:22
2
2
Those symlinks are installed by the system package manager, you potentially just broke your users system. Manually deleting symlinks is not a solution I would accept for a program unless it was very early development and I was participating.
– crasic
Mar 22 at 20:18
Those symlinks are installed by the system package manager, you potentially just broke your users system. Manually deleting symlinks is not a solution I would accept for a program unless it was very early development and I was participating.
– crasic
Mar 22 at 20:18
1
1
@BrianSizemore and @crasic are right. You're asking for trouble using a name that's so generic. There's a pretty high likelihood of users having an alias or shell function named
open that wraps commonly-used commands. As like @Zanna said, aliases will always take precedence over other commands.– Alhadis
Mar 23 at 4:07
@BrianSizemore and @crasic are right. You're asking for trouble using a name that's so generic. There's a pretty high likelihood of users having an alias or shell function named
open that wraps commonly-used commands. As like @Zanna said, aliases will always take precedence over other commands.– Alhadis
Mar 23 at 4:07
 |Â
show 2 more comments
2 Answers
2
active
oldest
votes
up vote
9
down vote
accepted
The reason that /bin/open takes precedence over /usr/bin/open on your system is presumably that /bin comes before /usr/bin in your PATH. To examine your PATH, you can run echo $PATH. The elements are separated with colons.
You got the command you wanted when you used (I assume) sudo to run open or to start a root shell in which you ran it, because sudo uses its own PATH, defined in /etc/sudoers as secure_path, which on my system is
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin
As you can see, /usr/bin comes before /bin.
I think your finding is odd, because as far as I know, /usr/bin usually comes before /bin. Your users may not have the same problem as you.
However, to be safe, you could have your program be installed in /usr/local/bin, which should always come before /usr/bin and /bin in a user's PATH so that software built locally takes precedence over other commands with the same name.
Even safer, as steeldriver suggested, have your users (or your installation script) define an alias for your tool in a shell configuration file such as ~/.bashrc. Aliases always take precedence over other commands. By putting an alias in your ~/.bashrc you ensure that it will only be known to interactive shells, and will not interfere with other programs.
Deleting the symlink could cause problems if programs try to execute /bin/open expecting openvt, and may be unreliable, as pointed out by steeldriver, because the symlink might be recreated when the package that provides it is updated or reinstalled (i.e. fairly unpredictably).
answered Mar 22 at 18:09
Zanna
48k13119228
1
I think that's a very good point. I'll try to create a link in my own .bashrc file and when I've got it right, I advise that others to the same.
– James Smith
Mar 22 at 18:46
That worked! I put the symbolic link back first, then added the alias and all is well.
– James Smith
Mar 22 at 18:50
@JamesSmith great! Maybe you want to edit your own answer to show your updated solution (where you put the alias and your assignment etc)
– Zanna
Mar 22 at 18:53
Okay, I'll do that.
– James Smith
Mar 22 at 18:54
add a comment |Â
up vote
2
down vote
In fact there was a symbolic link open -> openvt in the /bin directory. Removing this link fixed the problem. However, by far the best solution, as mentioned elsewhere, is to create an alias on your .bashrc file...
Navigate to your home directory:
cd ~
Edit your .bashrc (here I've used nano but there plenty of options):
nano .bashrc
Put the following somewhere (perhaps at the foot):
alias open='/usr/lib/node_modules/occam-open-cli/open.js'
You can reload the file by typing source .bashrc and you're good to go without affecting anything else.
answered Mar 22 at 17:42
James Smith
1618
This is interesting, because I think/bincomes after/usr/binin the default PATH. If you look at thesecure_pathin/etc/sudoersyou should see that/usr/bincomes before/bin, and that's why you got the command you wanted withsudo(assuming you usedsudoto run the command or open a root shell). Rather than deleting the symlink, check your PATH. Perhaps you should get your tool to install in/usr/local/binwhich is always before/usr/binand/binin the default PATH. Hmm. Perhaps this comment is an answer... Still, +1...
– Zanna
Mar 22 at 17:47
1
@Zanna yes please make that an answer - perhaps creating an alias would be even better (since that won't mess with non-interactive environments that may expectopento beopenvt). IMHO removing the symlink is the worst solution of the three - if the package that created it (packagekbdiirc) gets updated or re-installed, there's a good chance the link will get re-created.
– steeldriver
Mar 22 at 17:51
@steeldriver thanks a lot! I have used your insights in my answer, assuming you didn't want to write one...
– Zanna
Mar 22 at 18:16
1
@Zanna I missed the part about the path order - your answer is spot on IMHO
– steeldriver
Mar 22 at 18:52
add a comment |Â
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
9
down vote
accepted
The reason that /bin/open takes precedence over /usr/bin/open on your system is presumably that /bin comes before /usr/bin in your PATH. To examine your PATH, you can run echo $PATH. The elements are separated with colons.
You got the command you wanted when you used (I assume) sudo to run open or to start a root shell in which you ran it, because sudo uses its own PATH, defined in /etc/sudoers as secure_path, which on my system is
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin
As you can see, /usr/bin comes before /bin.
I think your finding is odd, because as far as I know, /usr/bin usually comes before /bin. Your users may not have the same problem as you.
However, to be safe, you could have your program be installed in /usr/local/bin, which should always come before /usr/bin and /bin in a user's PATH so that software built locally takes precedence over other commands with the same name.
Even safer, as steeldriver suggested, have your users (or your installation script) define an alias for your tool in a shell configuration file such as ~/.bashrc. Aliases always take precedence over other commands. By putting an alias in your ~/.bashrc you ensure that it will only be known to interactive shells, and will not interfere with other programs.
Deleting the symlink could cause problems if programs try to execute /bin/open expecting openvt, and may be unreliable, as pointed out by steeldriver, because the symlink might be recreated when the package that provides it is updated or reinstalled (i.e. fairly unpredictably).
answered Mar 22 at 18:09
Zanna
48k13119228
1
I think that's a very good point. I'll try to create a link in my own .bashrc file and when I've got it right, I advise that others to the same.
– James Smith
Mar 22 at 18:46
That worked! I put the symbolic link back first, then added the alias and all is well.
– James Smith
Mar 22 at 18:50
@JamesSmith great! Maybe you want to edit your own answer to show your updated solution (where you put the alias and your assignment etc)
– Zanna
Mar 22 at 18:53
Okay, I'll do that.
– James Smith
Mar 22 at 18:54
add a comment |Â
up vote
9
down vote
accepted
The reason that /bin/open takes precedence over /usr/bin/open on your system is presumably that /bin comes before /usr/bin in your PATH. To examine your PATH, you can run echo $PATH. The elements are separated with colons.
You got the command you wanted when you used (I assume) sudo to run open or to start a root shell in which you ran it, because sudo uses its own PATH, defined in /etc/sudoers as secure_path, which on my system is
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin
As you can see, /usr/bin comes before /bin.
I think your finding is odd, because as far as I know, /usr/bin usually comes before /bin. Your users may not have the same problem as you.
However, to be safe, you could have your program be installed in /usr/local/bin, which should always come before /usr/bin and /bin in a user's PATH so that software built locally takes precedence over other commands with the same name.
Even safer, as steeldriver suggested, have your users (or your installation script) define an alias for your tool in a shell configuration file such as ~/.bashrc. Aliases always take precedence over other commands. By putting an alias in your ~/.bashrc you ensure that it will only be known to interactive shells, and will not interfere with other programs.
Deleting the symlink could cause problems if programs try to execute /bin/open expecting openvt, and may be unreliable, as pointed out by steeldriver, because the symlink might be recreated when the package that provides it is updated or reinstalled (i.e. fairly unpredictably).
answered Mar 22 at 18:09
Zanna
48k13119228
1
I think that's a very good point. I'll try to create a link in my own .bashrc file and when I've got it right, I advise that others to the same.
– James Smith
Mar 22 at 18:46
That worked! I put the symbolic link back first, then added the alias and all is well.
– James Smith
Mar 22 at 18:50
@JamesSmith great! Maybe you want to edit your own answer to show your updated solution (where you put the alias and your assignment etc)
– Zanna
Mar 22 at 18:53
Okay, I'll do that.
– James Smith
Mar 22 at 18:54
add a comment |Â
up vote
9
down vote
accepted
up vote
9
down vote
accepted
The reason that /bin/open takes precedence over /usr/bin/open on your system is presumably that /bin comes before /usr/bin in your PATH. To examine your PATH, you can run echo $PATH. The elements are separated with colons.
You got the command you wanted when you used (I assume) sudo to run open or to start a root shell in which you ran it, because sudo uses its own PATH, defined in /etc/sudoers as secure_path, which on my system is
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin
As you can see, /usr/bin comes before /bin.
I think your finding is odd, because as far as I know, /usr/bin usually comes before /bin. Your users may not have the same problem as you.
However, to be safe, you could have your program be installed in /usr/local/bin, which should always come before /usr/bin and /bin in a user's PATH so that software built locally takes precedence over other commands with the same name.
Even safer, as steeldriver suggested, have your users (or your installation script) define an alias for your tool in a shell configuration file such as ~/.bashrc. Aliases always take precedence over other commands. By putting an alias in your ~/.bashrc you ensure that it will only be known to interactive shells, and will not interfere with other programs.
Deleting the symlink could cause problems if programs try to execute /bin/open expecting openvt, and may be unreliable, as pointed out by steeldriver, because the symlink might be recreated when the package that provides it is updated or reinstalled (i.e. fairly unpredictably).
answered Mar 22 at 18:09
Zanna
48k13119228
The reason that /bin/open takes precedence over /usr/bin/open on your system is presumably that /bin comes before /usr/bin in your PATH. To examine your PATH, you can run echo $PATH. The elements are separated with colons.
You got the command you wanted when you used (I assume) sudo to run open or to start a root shell in which you ran it, because sudo uses its own PATH, defined in /etc/sudoers as secure_path, which on my system is
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin
As you can see, /usr/bin comes before /bin.
I think your finding is odd, because as far as I know, /usr/bin usually comes before /bin. Your users may not have the same problem as you.
However, to be safe, you could have your program be installed in /usr/local/bin, which should always come before /usr/bin and /bin in a user's PATH so that software built locally takes precedence over other commands with the same name.
Even safer, as steeldriver suggested, have your users (or your installation script) define an alias for your tool in a shell configuration file such as ~/.bashrc. Aliases always take precedence over other commands. By putting an alias in your ~/.bashrc you ensure that it will only be known to interactive shells, and will not interfere with other programs.
Deleting the symlink could cause problems if programs try to execute /bin/open expecting openvt, and may be unreliable, as pointed out by steeldriver, because the symlink might be recreated when the package that provides it is updated or reinstalled (i.e. fairly unpredictably).
answered Mar 22 at 18:09
Zanna
48k13119228
edited Mar 22 at 18:56
answered Mar 22 at 18:09
Zanna
48k13119228
answered Mar 22 at 18:09
Zanna
48k13119228
answered Mar 22 at 18:09
Zanna
48k13119228
48k13119228
1
I think that's a very good point. I'll try to create a link in my own .bashrc file and when I've got it right, I advise that others to the same.
– James Smith
Mar 22 at 18:46
That worked! I put the symbolic link back first, then added the alias and all is well.
– James Smith
Mar 22 at 18:50
@JamesSmith great! Maybe you want to edit your own answer to show your updated solution (where you put the alias and your assignment etc)
– Zanna
Mar 22 at 18:53
Okay, I'll do that.
– James Smith
Mar 22 at 18:54
add a comment |Â
1
I think that's a very good point. I'll try to create a link in my own .bashrc file and when I've got it right, I advise that others to the same.
– James Smith
Mar 22 at 18:46
That worked! I put the symbolic link back first, then added the alias and all is well.
– James Smith
Mar 22 at 18:50
@JamesSmith great! Maybe you want to edit your own answer to show your updated solution (where you put the alias and your assignment etc)
– Zanna
Mar 22 at 18:53
Okay, I'll do that.
– James Smith
Mar 22 at 18:54
1
1
I think that's a very good point. I'll try to create a link in my own .bashrc file and when I've got it right, I advise that others to the same.
– James Smith
Mar 22 at 18:46
I think that's a very good point. I'll try to create a link in my own .bashrc file and when I've got it right, I advise that others to the same.
– James Smith
Mar 22 at 18:46
That worked! I put the symbolic link back first, then added the alias and all is well.
– James Smith
Mar 22 at 18:50
That worked! I put the symbolic link back first, then added the alias and all is well.
– James Smith
Mar 22 at 18:50
@JamesSmith great! Maybe you want to edit your own answer to show your updated solution (where you put the alias and your assignment etc)
– Zanna
Mar 22 at 18:53
@JamesSmith great! Maybe you want to edit your own answer to show your updated solution (where you put the alias and your assignment etc)
– Zanna
Mar 22 at 18:53
Okay, I'll do that.
– James Smith
Mar 22 at 18:54
Okay, I'll do that.
– James Smith
Mar 22 at 18:54
add a comment |Â
up vote
2
down vote
In fact there was a symbolic link open -> openvt in the /bin directory. Removing this link fixed the problem. However, by far the best solution, as mentioned elsewhere, is to create an alias on your .bashrc file...
Navigate to your home directory:
cd ~
Edit your .bashrc (here I've used nano but there plenty of options):
nano .bashrc
Put the following somewhere (perhaps at the foot):
alias open='/usr/lib/node_modules/occam-open-cli/open.js'
You can reload the file by typing source .bashrc and you're good to go without affecting anything else.
answered Mar 22 at 17:42
James Smith
1618
This is interesting, because I think/bincomes after/usr/binin the default PATH. If you look at thesecure_pathin/etc/sudoersyou should see that/usr/bincomes before/bin, and that's why you got the command you wanted withsudo(assuming you usedsudoto run the command or open a root shell). Rather than deleting the symlink, check your PATH. Perhaps you should get your tool to install in/usr/local/binwhich is always before/usr/binand/binin the default PATH. Hmm. Perhaps this comment is an answer... Still, +1...
– Zanna
Mar 22 at 17:47
1
@Zanna yes please make that an answer - perhaps creating an alias would be even better (since that won't mess with non-interactive environments that may expectopento beopenvt). IMHO removing the symlink is the worst solution of the three - if the package that created it (packagekbdiirc) gets updated or re-installed, there's a good chance the link will get re-created.
– steeldriver
Mar 22 at 17:51
@steeldriver thanks a lot! I have used your insights in my answer, assuming you didn't want to write one...
– Zanna
Mar 22 at 18:16
1
@Zanna I missed the part about the path order - your answer is spot on IMHO
– steeldriver
Mar 22 at 18:52
add a comment |Â
up vote
2
down vote
In fact there was a symbolic link open -> openvt in the /bin directory. Removing this link fixed the problem. However, by far the best solution, as mentioned elsewhere, is to create an alias on your .bashrc file...
Navigate to your home directory:
cd ~
Edit your .bashrc (here I've used nano but there plenty of options):
nano .bashrc
Put the following somewhere (perhaps at the foot):
alias open='/usr/lib/node_modules/occam-open-cli/open.js'
You can reload the file by typing source .bashrc and you're good to go without affecting anything else.
answered Mar 22 at 17:42
James Smith
1618
This is interesting, because I think/bincomes after/usr/binin the default PATH. If you look at thesecure_pathin/etc/sudoersyou should see that/usr/bincomes before/bin, and that's why you got the command you wanted withsudo(assuming you usedsudoto run the command or open a root shell). Rather than deleting the symlink, check your PATH. Perhaps you should get your tool to install in/usr/local/binwhich is always before/usr/binand/binin the default PATH. Hmm. Perhaps this comment is an answer... Still, +1...
– Zanna
Mar 22 at 17:47
1
@Zanna yes please make that an answer - perhaps creating an alias would be even better (since that won't mess with non-interactive environments that may expectopento beopenvt). IMHO removing the symlink is the worst solution of the three - if the package that created it (packagekbdiirc) gets updated or re-installed, there's a good chance the link will get re-created.
– steeldriver
Mar 22 at 17:51
@steeldriver thanks a lot! I have used your insights in my answer, assuming you didn't want to write one...
– Zanna
Mar 22 at 18:16
1
@Zanna I missed the part about the path order - your answer is spot on IMHO
– steeldriver
Mar 22 at 18:52
add a comment |Â
up vote
2
down vote
up vote
2
down vote
In fact there was a symbolic link open -> openvt in the /bin directory. Removing this link fixed the problem. However, by far the best solution, as mentioned elsewhere, is to create an alias on your .bashrc file...
Navigate to your home directory:
cd ~
Edit your .bashrc (here I've used nano but there plenty of options):
nano .bashrc
Put the following somewhere (perhaps at the foot):
alias open='/usr/lib/node_modules/occam-open-cli/open.js'
You can reload the file by typing source .bashrc and you're good to go without affecting anything else.
answered Mar 22 at 17:42
James Smith
1618
In fact there was a symbolic link open -> openvt in the /bin directory. Removing this link fixed the problem. However, by far the best solution, as mentioned elsewhere, is to create an alias on your .bashrc file...
Navigate to your home directory:
cd ~
Edit your .bashrc (here I've used nano but there plenty of options):
nano .bashrc
Put the following somewhere (perhaps at the foot):
alias open='/usr/lib/node_modules/occam-open-cli/open.js'
You can reload the file by typing source .bashrc and you're good to go without affecting anything else.
answered Mar 22 at 17:42
James Smith
1618
edited Mar 22 at 18:58
answered Mar 22 at 17:42
James Smith
1618
answered Mar 22 at 17:42
James Smith
1618
answered Mar 22 at 17:42
James Smith
1618
1618
This is interesting, because I think/bincomes after/usr/binin the default PATH. If you look at thesecure_pathin/etc/sudoersyou should see that/usr/bincomes before/bin, and that's why you got the command you wanted withsudo(assuming you usedsudoto run the command or open a root shell). Rather than deleting the symlink, check your PATH. Perhaps you should get your tool to install in/usr/local/binwhich is always before/usr/binand/binin the default PATH. Hmm. Perhaps this comment is an answer... Still, +1...
– Zanna
Mar 22 at 17:47
1
@Zanna yes please make that an answer - perhaps creating an alias would be even better (since that won't mess with non-interactive environments that may expectopento beopenvt). IMHO removing the symlink is the worst solution of the three - if the package that created it (packagekbdiirc) gets updated or re-installed, there's a good chance the link will get re-created.
– steeldriver
Mar 22 at 17:51
@steeldriver thanks a lot! I have used your insights in my answer, assuming you didn't want to write one...
– Zanna
Mar 22 at 18:16
1
@Zanna I missed the part about the path order - your answer is spot on IMHO
– steeldriver
Mar 22 at 18:52
add a comment |Â
This is interesting, because I think/bincomes after/usr/binin the default PATH. If you look at thesecure_pathin/etc/sudoersyou should see that/usr/bincomes before/bin, and that's why you got the command you wanted withsudo(assuming you usedsudoto run the command or open a root shell). Rather than deleting the symlink, check your PATH. Perhaps you should get your tool to install in/usr/local/binwhich is always before/usr/binand/binin the default PATH. Hmm. Perhaps this comment is an answer... Still, +1...
– Zanna
Mar 22 at 17:47
1
@Zanna yes please make that an answer - perhaps creating an alias would be even better (since that won't mess with non-interactive environments that may expectopento beopenvt). IMHO removing the symlink is the worst solution of the three - if the package that created it (packagekbdiirc) gets updated or re-installed, there's a good chance the link will get re-created.
– steeldriver
Mar 22 at 17:51
@steeldriver thanks a lot! I have used your insights in my answer, assuming you didn't want to write one...
– Zanna
Mar 22 at 18:16
1
@Zanna I missed the part about the path order - your answer is spot on IMHO
– steeldriver
Mar 22 at 18:52
This is interesting, because I think
/bin comes after /usr/bin in the default PATH. If you look at the secure_path in /etc/sudoers you should see that /usr/bin comes before /bin, and that's why you got the command you wanted with sudo (assuming you used sudo to run the command or open a root shell). Rather than deleting the symlink, check your PATH. Perhaps you should get your tool to install in /usr/local/bin which is always before /usr/bin and /bin in the default PATH. Hmm. Perhaps this comment is an answer... Still, +1...– Zanna
Mar 22 at 17:47
This is interesting, because I think
/bin comes after /usr/bin in the default PATH. If you look at the secure_path in /etc/sudoers you should see that /usr/bin comes before /bin, and that's why you got the command you wanted with sudo (assuming you used sudo to run the command or open a root shell). Rather than deleting the symlink, check your PATH. Perhaps you should get your tool to install in /usr/local/bin which is always before /usr/bin and /bin in the default PATH. Hmm. Perhaps this comment is an answer... Still, +1...– Zanna
Mar 22 at 17:47
1
1
@Zanna yes please make that an answer - perhaps creating an alias would be even better (since that won't mess with non-interactive environments that may expect
open to be openvt). IMHO removing the symlink is the worst solution of the three - if the package that created it (package kbd iirc) gets updated or re-installed, there's a good chance the link will get re-created.– steeldriver
Mar 22 at 17:51
@Zanna yes please make that an answer - perhaps creating an alias would be even better (since that won't mess with non-interactive environments that may expect
open to be openvt). IMHO removing the symlink is the worst solution of the three - if the package that created it (package kbd iirc) gets updated or re-installed, there's a good chance the link will get re-created.– steeldriver
Mar 22 at 17:51
@steeldriver thanks a lot! I have used your insights in my answer, assuming you didn't want to write one...
– Zanna
Mar 22 at 18:16
@steeldriver thanks a lot! I have used your insights in my answer, assuming you didn't want to write one...
– Zanna
Mar 22 at 18:16
1
1
@Zanna I missed the part about the path order - your answer is spot on IMHO
– steeldriver
Mar 22 at 18:52
@Zanna I missed the part about the path order - your answer is spot on IMHO
– steeldriver
Mar 22 at 18:52
add a comment |Â
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
var $window = $(window),
onScroll = function(e)
var $elem = $('.new-login-left'),
docViewTop = $window.scrollTop(),
docViewBottom = docViewTop + $window.height(),
elemTop = $elem.offset().top,
elemBottom = elemTop + $elem.height();
if ((docViewTop elemBottom))
StackExchange.using('gps', function() StackExchange.gps.track('embedded_signup_form.view', location: 'question_page' ); );
$window.unbind('scroll', onScroll);
;
$window.on('scroll', onScroll);
);
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%2faskubuntu.com%2fquestions%2f1018316%2fhow-do-i-disable-the-open-command-knowing-that-it-is-just-a-link-to-the-open%23new-answer', 'question_page');
);
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
var $window = $(window),
onScroll = function(e)
var $elem = $('.new-login-left'),
docViewTop = $window.scrollTop(),
docViewBottom = docViewTop + $window.height(),
elemTop = $elem.offset().top,
elemBottom = elemTop + $elem.height();
if ((docViewTop elemBottom))
StackExchange.using('gps', function() StackExchange.gps.track('embedded_signup_form.view', location: 'question_page' ); );
$window.unbind('scroll', onScroll);
;
$window.on('scroll', onScroll);
);
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');
var $window = $(window),
onScroll = function(e)
var $elem = $('.new-login-left'),
docViewTop = $window.scrollTop(),
docViewBottom = docViewTop + $window.height(),
elemTop = $elem.offset().top,
elemBottom = elemTop + $elem.height();
if ((docViewTop elemBottom))
StackExchange.using('gps', function() StackExchange.gps.track('embedded_signup_form.view', location: 'question_page' ); );
$window.unbind('scroll', onScroll);
;
$window.on('scroll', onScroll);
);
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');
var $window = $(window),
onScroll = function(e)
var $elem = $('.new-login-left'),
docViewTop = $window.scrollTop(),
docViewBottom = docViewTop + $window.height(),
elemTop = $elem.offset().top,
elemBottom = elemTop + $elem.height();
if ((docViewTop elemBottom))
StackExchange.using('gps', function() StackExchange.gps.track('embedded_signup_form.view', location: 'question_page' ); );
$window.unbind('scroll', onScroll);
;
$window.on('scroll', onScroll);
);
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
3
I might be misreading your question, but if you type
type -a open, it should show you all the things thatopenmeans to the shell– Zanna
Mar 22 at 17:29
Thanks. I tried it. I get
/usr/bin/openand/bin/open. I'll investigate what this are, whether links or binaries...– James Smith
Mar 22 at 17:36
17
Just as a suggestion, maybe you should try avoiding using such a generic name for your tool. The fact that you are deleting symlinks that are default on your system already means that someone used to using such a symlink that installs your product is going to see some frustrations. Let alone the fact that someone else may come up with another utility and want to use simply
openas the command as well.– Brian Sizemore
Mar 22 at 18:22
2
Those symlinks are installed by the system package manager, you potentially just broke your users system. Manually deleting symlinks is not a solution I would accept for a program unless it was very early development and I was participating.
– crasic
Mar 22 at 20:18
1
@BrianSizemore and @crasic are right. You're asking for trouble using a name that's so generic. There's a pretty high likelihood of users having an alias or shell function named
openthat wraps commonly-used commands. As like @Zanna said, aliases will always take precedence over other commands.– Alhadis
Mar 23 at 4:07