Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 8 years ago.
Improve this question
Recently I play with an awesome programming language red. After I downloaded it on my Linux Box, and typed red --version, I got something unexpected:
$ red --version
GNU ed version 0.2
then I look up ed's manual, it's said it also named red, but don't explain why?
So does anyone know the secret history of ed's name, maybe it's a wonderful story. ;-)
Read GNU ed documentation, chapter on invoking ed. Running red is like running ed -r i.e. running it in ....
-r
--restricted
Run in restricted mode. This mode disables edition of files out of
the current directory and execution of shell commands.
BTW, bash (and several other utilities) have a restricted mode also, e.g. when invoked as rbash ....
And GNU ed manual says
A restricted version of ed, red, can only edit files in the current directory and cannot execute shell commands.
BTW, perhaps your red compiler got installed at some different path like /usr/local/bin/red. Try typing this (or some similar) path in full to invoke it. Learn about the role of PATH e.g. in environ(7) and execvp(3) etc... Perhaps edit your .bashrc to change your PATH or add a symlink from $HOME/bin/red to e.g. /usr/local/bin/red
The same happened to me a while ago, and it thought that Red had been packaged for my favourite Debian! Hélas, not.
I noted that the "red" executable belonging to ed package is /only a symlink to ed, at least on my debian:
# pierre#autan: ~ < 2013_10_13__12_16_23 >
ll /usr/bin/red
lrwxrwxrwx 1 root root 7 mai 12 19:10 /usr/bin/red -> /bin/ed
This leads to a point that I brought, a few months ago: I find that the name "Red" is a bit too general, and may be confusing. WHile googling "rebol" leads to many relevant matches, googling "red" leads to a tremendous amount of irrelevant stuff. However, as #DocKimbel (Red's author) pointed out, googling "red language" immediately leads to relevant URLs.
Now, what to do:
from Red's side: change "red" to another name, like red_lang ? so that ed and its red "alias" may still be used
from ed's side: get in the package and have it remove the red symlink. We should carefully check for dependencies.
Note that the first option is about programming: the future of Red, which is coming to life right now, depends on these kind of "details", and it concerns all programmers who will be coding in Red soon (plenty!;)).
The second option is not about programming at all: mea culpa.
As #HostileFork pointed out on https://chat.stackoverflow.com/rooms/291/rebol-and-red , ed is quite an old-fashioned tool: I suppose it must be still /only used by some scripts, and not that much by "normally-minded" human beings.
(I drifted a bit off-opic, didn't I? Sorry...)
Related
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 7 years ago.
Improve this question
I don't want to install multiple instances of perl.
How can I upgrade my Perl to latest version or delete existing Perl installation and install a new version of Perl in Ubuntu 14.04.
After new installation, will it conflict with older installation files.
I'd do it like this:
wget http://www.cpan.org/src/5.0/perl-5.22.1.tar.gz
tar xvfz perl-5.22.1.tar.gz
cd perl-5.22.1 && ./Configure -Duseithreads -des && make && make test && make install
/usr/local/bin/cpan -u
This puts a source build of perl in /usr/local/bin
Then check your path has /usr/local/bin in it, and if you want typing perl to run your new perl, ensure it's in front of /usr/bin (this is a fairly common scenario, but I can't say for sure if that applies.
Whilst you say you don't want to install multiple perl versions - this is a bad idea.
perl is distributed as part of your operating system. Packages depend upon it, and the particular version. You cannot tell what you might break by altering versions - not least because the way perl handles certain things does change between versions (like hashes).
Messing around with /usr/bin/perl is a road to some future pain (not least - it makes an 'update' of your OS annoyingly difficult, because you can no longer use the package manager without a bit of hackery)
If you REALLY REALLY want to do that you can set -Dprefix= in your Configure options. But as a sysadmin of 15 years experience, I can tell you - no good will come of it, you will break your OS in a variety of minor, but cumulatively really annoying ways. (And maybe some bigger ways)
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 7 years ago.
Improve this question
I recently switched from Linux to OSX. I use console heavily, and previously I was able to do things like
ls ./dir -sgh
cp ./file ./dir -Rf
and so on. If I missed an option, it was enough to press up and just add it. OSX forces me to put options before arguments, like this:
ls -sgh ./dir
cp -Rf ./file ./dir
This behavior is frustrating, it is easy to forget about an option and you have to navigate to the beggining of a line just to add it. It is also hard to add another option if you forget about one.
Is there an easy way to fix this behavior and make it work the linux way? I guess it involves replacing default programs like ls with some counterparts.
OS X's userland is a mash of BSD, (outdated) GNU, and Apple utilities.
If want your utilities to behave like their Linux counterparts, you should probably install the entire GNU coreutils suite with something like
Homebrew.
Once Homebrew is installed, just use it to install the coreutils:
$ brew install coreutils
Edit: I didn't have to update my $PATH personally, but YMMV.
If your shell isn't finding the Homebrew-installed coreutils, make sure /usr/local/bin (or your custom path, if Homebrew was configured as such) is before /usr/bin and /bin on $PATH.
In the best-case scenario, all programs dynamically link the system libc and use getopt to process their arguments. getopt only looks at arguments until it finds the first non-option argument, then stops. You cannot change this behavior of getopt. You would have to replace the system libc with one having a different implementation of getopt.
However, there is no guaranteed that all programs load libc dynamically; some might link statically, in which case replacing the system libc would have no effect. Others may not even use getopt. In either case, the only option is to replace the program with one that behaves the way you want.
Option processing is not a feature of the shell. You'd need to patch the argument processing logic in each individual utility.
Alternatively, you could install e.g. the corresponding GNU utilities. They are not completely option-compatible with the default *BSD utilities, so you can't replace the system binaries; but you can arrange your PATH so that the locally installed versions are preferred for your personal use. Homebrew is popular for managing this.
In Bash, ctrl-A jumps to the beginning of line, and M-n jumps past the first token.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 8 years ago.
Improve this question
I found both git --version and git version are okay. They will show me the same output. However, if I try some other command, say, ls -l and ls l, only the first works.
I'd like to know how the arguments work in command line. When and where the dash or double dash before flag/arguments are necessary? Or I might be wrong with some concept when using the shell.
Thanks!
This is command dependent. There are some common commands like git or tar who have optional dashes. Most do not. You really have to read the man page to see what the command expects.
There are basically two styles for providing arguments on the command line.
The GNU style is characterized by characterized by options that look like this (-v) or like this (--verbose). The single dash sets of "short" options and the double-dash sets off "long" options. Not every short option will have a corresponding long option, or vice-versa. This syntax permits short options that do not take option arguments to be combined (for example, ls -al is equivalent to ls -a -l).
In the BSD style, one can have an option that looks like this: java -version where -version a single option, which may or may not take an argument. This style has evolved into one where complex commands have many subcommands, typically referred to as "verbs." This style is used by Apple in OSX, for example launchctl unload /path/to/some.plist ("unload" is the verb).
Hopefully this information will help you read the documentation as you go. You can find the options, and what they do, for any command, by executing, for example man ls. Note that, in some cases, there is more than one manpage for a given name. In this case, you can provide the section of the manual in which you would like to do the look up, eg man 1 crontab to see how to use the program that edits users crontabs, and man 5 crontab to see the format of an entry in these tables.
Understanding these families is useful. The authors of these commands do not want to reimplement option parsing, so they use one of the common libraries for performing this task. Thus, if you encounter a new command, once you know what family it falls into, you will have an easier time understanding the manpage.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 9 years ago.
Improve this question
This question arose in my mind while I was installing JDK on Ubuntu. While I was installing JDK the steps are -
Extracting the .bin file of java.
Make a directory named java6 in /usr/lib and move all the content of extracted .bin file to the /usr/lib/java6.
Now soft a soft link is created in the current directory like this-
ln -s java6 java
I am surprised that the newly created link 'java' is used to set "JAVA_HOME" environment variable. As far as I know a similar thing is not possible in Windows.
More over while I am installing nexus I noticed the following -
$ ln -s nexus-2.7-06-bundle nexus
$ cd nexus
$ ./bin/nexus console
What I am trying to say here is - first we access the link directory (nexus), then we are running script (in /bin/nexus). I noticed these two approaches in several tutorials. I think these approaches should have some benefits.
Now my questions are that -
Why a link (/usr/lib/java) is set as JAVA_HOME; what is the advantage of doing so?
Why we are running the script (... /bin/nexus) from going to the soft link directory and what is the advantage of doing so?
When I am using the base directory instead of the link for the mentioned two cases, it also works fine. So, why these approaches?
If you install java7 instead of java6 (or java7 parallel to java6
or something else like that), if the JAVA_HOME variable and 100 other things are set
explicitly to java6, you would have to change them all to java7.
(and it is not trivial to find all config stuff which need changes).
With the link, you set all config stuff to the link and change only the link if necessary.And yes, this is possible on Windows too.
1) Why a link (/usr/lib/java) is set as JAVA_HOME; what is the advantage of doing so?
JAVA_HOME points to java you want to use (say java6)
JAVA_HOME is just a convention, usually software like eclipse, maven etc... use it to find where Java is located.
And yea it can be done in Windows too.
2) Why we are running the script (... /bin/nexus) from going to the soft link directory and what is the advantage of doing so?
Advantage none (It depends on you how you see it)
This Q is somewhat similar to Q1..
Say in future you want to use new version nexus-2.8-*. So instead of changing all configuration from nexus-2.7-* to nexus-2.8-*; you can just change the soft link nexus(to point the new version)
3) When I am using the base directory instead of the link for the mentioned two cases, it also works fine. So, why these approaches?
You answered you own Q!
Yep its a link; so nexus --> nexus-2.7-06-bundle; one and the same...
why the approach? see 3rd point of previous Q
Think of soft link as shortcut in Windows
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 8 years ago.
Improve this question
My KDE is broken, the desktop Widgets cannot be displayed. And many KDE programs look like this:
All the software written in GTK is all right.
Can any one give me any suggestion about what's happening and which part is broken?
Where can I find error log?
You don't say what disto you're using (please add it to the tags in your question), nor how you got in this state - new installation? dist-upgrade? hard crash? That would be useful information.
But in general, here's what I would try:
Log out and go to a bare terminal with CTRL-ALT-F1, then login and rename your .kde / .kde4 directories: mv ~/.kde ~/.kde.old and reboot or otherwise restart your GUI system.
That will at least tell you whether the problem is messed up personal settings or messed-up system files.
If that doesn't fix the issue (that directory will be recreated when you start up KDE again; all your settings will be lost, but you can recover them - carefully, one by one - from the backup you just made), then I would first try sudo apt-get check (assuming you're on a Debian-based distro).
If that doesn't report any problems, then I would update my system - possibly even do a dist-upgrade without changes any sources.
If this issue still wasn't fixed, I would run sudo dpkg -l > ~/Desktop/dpkg_out.txt to get a list of installed or uninstalled packages and their state in a file, and then look through the file for problems as explained here.
Finally, if all of that failed, I would take a good hard look at my video drivers.
Good luck!