Write parameter 'options single-request' in /etc/resolv.conf, the font become red.Red means this parameter has a syntax error, but i don't know where am i wrong. My /etc/resolv.conf as below:
options single-request
nameserver 10.11.199.119
Red means this parameter has a syntax error
No, it doesn't.
It means that whatever editor you are using doesn't understand that syntax. But what actually matters is whether your GLIBC understands that syntax (GLIBC >= 2.10 should, according to the man page).
My glibc is 2.17. So why system didn't understand "options single-request"?
There is no such thing as "system" here.
The /etc/resolv.conf is just a text file, it doesn't "understand" anything. You can edit that text file using a variety of editors: vi, gvim, emacs, or no editor at all (you can use echo or cat to create that file).
Now, a particular editor you used (but didn't tell us what that editor is), pretends to understand the file syntax, performs syntax highlighting, and even highlights "mistakes" in red. But that particular editor has simply not been updated when the new GLIBC syntax was implemented. The GLIBC developers all use vi or emacs, and probably don't even know that that editor exists.
So when you say "why did the system not understand ...", what you are really asking is "why haven't the developers of that editor that you are using updated it to understand ...". There could be a few reasons for that: they may not know about the new syntax, or they may have abandoned that editor, or they may have already fixed it but the fix hasn't been included in your OS release.
Most probably it has to be:
options single-request-reopen
?
Related
I'm trying to figure out which language is used in Linux scripts to make the system more personal? I mean things like you put in the dotfiles — like .vimrc, or .zshrc — or to make a function for the terminal (like one that compiles a .tex file with bibtex and then pdflatex and then opens that .pdf with some reader).
What you call dotfiles are just configuration files of one or another program. So the "language" of each of those configuration files depends on the program that is going to use it.
In fact, that doesn't have to be a language, in general, hence the quotes in the previous paragraph. Those config files just have to match the format that the program that uses them expects. This occasionally means that configuarion files are required to use a specific language; an example is .vimrc, which has to use the vimscript language (aka VimL).
I think the term "Linux Scripts" will cause misunderstandment in here.
These dotfiles have a particular syntax for each one, but it's not a programming language.
It's allways a good idea to read the official documentation.
https://www.vim.org/docs.php
https://www.zsh.org/
For vimscript learning, I had a good experience with this one:
https://learnvimscriptthehardway.stevelosh.com/
This is a very specific issue but, based on what I've seen online, a surprisingly common one. I'm on a rather old version of Scientific Linux 5, which is based on Red Hat. I use vim with the Solarized vim color scheme, and my TERM environment variable is usually set to xterm-256color. This worked fine until I started using tmux. On non-empty lines in vim, the color scheme only extended to the end of the document's characters, the remaining whitespace being plain back background.
The stock fix for this in online guides is to set TERM='screen-256color'. However, upon doing this I would get the ominous warning: WARNING: terminal is not fully functional - (press RETURN), when trying to do innocuous things like read man pages. However, everything seemed to be working fine, and the Solarized bug was fixed.
I've found a functional fix - using TERM='xterm-256color' by default and adding this line to my .bashrc:
alias v='function _vim(){ TERM='screen-256color'; vim $1; TERM='xterm-256color'; };_vim'
but it seems like a hack. Anecdotally, I've also set alias tmux='tmux -2', which is a common suggestion with color-scheme-related issues.
I also know that the terminfo screen-256color is available on my machine.
So, really, the main befuddling thing is that, when using TERM='screen-256color', I'm getting those warnings about full functionality when nothing seems to be wrong.
I don't have root access, so ideally any fix suggestions wouldn't need that.
EDIT: I should mention that TERM='screen-256color-bce' gave the same problems as TERM='screen-256color'.
The user's environment is not specified, but likely using bash and less (Scientific Linux 5 does not have more).
The package list on Scientific Linux 5's ftp site, shows ncurses-5.5-24.20060715.src.rpm, which does not include screen-256color (it was added to ncurses in October 2006). That system might have the later terminal database by some post-install change.
An application using termcap would not see this terminal description. Scientific Linux's bash and less programs could have used termcap rather than terminfo. A quick check of the changelog for bash-3.2-21.el5 says
* Fri Feb 1 2008 Miroslav Lichvar <mlichvar#redhat.com> - 3.2-21
- Link with libtermcap
On some systems, a missing termcap entry will cause a warning. But with Scientific Linux 5, the given warning message comes from less, which checks its terminal description (using the termcap interface), to ensure that it can clear the remainder of the current line, the remainder of the screen and the entire screen.
In Scientific Linux 5, the less package is built with ncurses. A problem with less using TERM=screen-256color would be one of these possibilities
the screen-256color entry is not really installed, or
there is some problem with the termcap interface provided by ncurses.
While there were ongoing performance-fixes for the screen program around this time, the former seems the more likely, as seen in this discussion of a poorly-written entry for screen-256color in early 2006: Re: screen-256color terminfo entry?. What I get from reading this is that there was some poorly-written terminal description (not part of ncurses) which produced the problem. By the time it was proposed for inclusion in ncurses (October 2006), the problem had been repaired. In any case, it would have been corrected at that point.
In eclipse, if you change a variable name, eclipse will automatically change this variable's name in whole project.
Can vim do that too?
Vim is a text editor, not an IDE. Though it has some notion of a filetype's syntax, it does not fully parse nor understand the language's full syntax. Refactorings, even simple ones like Rename identifier, do require such full understanding (to be 100% correct).
There are attempts at refactoring support in Vim, most language-specific, some also generic. But I'd advise to keep using a real IDE for this (for its comfort, safety, and correctness), and instead use Vim only for simple, text-based replacements, using :bufdo substitute/... or macros, as described here.
Sort of.
Because it is not an IDE and thus doesn't understand anything about your code, Vim only sees text where you see a variable name. It can't infer anything from the scope or whatever. Without the use of some external program, renaming a variable in Vim is usually done with a buffer-wide or project-wide search/replace.
Since you didn't tell us what language you are working with we can't tell you if there is a language-specific solution for your needs.
try this plugin -> Clighter, for c-family rename-refactoring. It's based on clang, but there are limitations. Still in development
Background:
It seems that some text editors and IDEs are starting to get more "browser-like" in their features. Specifically, one such feature is the ability to treat ordinary text in an open text buffer as a hyperlink to another file, resource, or even a runnable command.
Programming this as an editor plugin or macro
Since this seems like a good idea, I have started programming some scripts and editor addons to do this very kind of thing, so that the user of a text editor can open or operate on links of the following style:
href="c:/files/foobar.txt" (click to open file)
href="c:/files/foobar.txt" jumpto="34" (jump to a line number)
href="c:/files/foobar.txt" find="Lorem" (jump to 1st line containing word)
href="find_in_files://c:/files" find="Lorem" (show all matching lines)
[[find_in_files://find=Lorem;exten=*.htm*]] (alternate syntax option)
href="redir://c:/files/feebar.txt" (replace current edit buffer)
href="run://c:/files/foobar.jpg" (open in default image editor)
[[run://c:/files/foobar.jpg;runwith=foo.exe]] (alternate syntax option)
Questions:
Is there any kind of emerging convention for forming text-based hyperlinks?
If there is a convention for this kind of thing, is there a published specification?
Is there an implementation of this idea in your favorite editor/IDE?
Is there an alternate pre-existing approach for this idea that does not use hyperlinks?
How is this feature handled in the "grand-daddy" editors? (Vim, Emacs)
Update:
It looks like the question could have been clarified, but it turns out that Emacs Org mode is one specific example of what I was looking for that answers all of my questions.
Emacs' Org-Mode has support for all kinds of Hyperlinks.
There are several script for Vim that add hyperlinks and markup. One of the most popular is Viki.
URLs, such as http://example.com/ (notice SO automatically links that), and sometimes a "www." prefix, just because it's so common. Email addresses are another example commonly recognized.
But not this quasi-xml-attribute stuff you have.
Of course not; once you try and make plain text follow some convention, you no longer have plain text.
Yes, see #5.
Yes, see #5.
It's extremely common for editors, especially programmers' editors, to have scripts, macros, tools, or whatever-they-want-to-call-it. Usually these are not controlled directly by the text in the file, but may use the file, filename, selection, cursor position, directory of the current file, etc. I expect many good programmers use such features without thinking about them anymore.
Mostly it sounds like you're trying to solve a problem that doesn't exist.
Surely the jumpto="34" and find="Lorem" could be replaced with web-browser-style # and ? marks.
So your second and third example would look like so:
href="c:/files/foobar.txt#34" (jump to a line number)
href="c:/files/foobar.txt?Lorem" (jump to 1st line containing word)
Although, as Roger Pate says above, it does sound like you're solving a problem that doesn't exist.
Emacs also has "find-file-at-point", which you can invoke with M-x ffap
See also LinkD. Nothing fancy like Org. Simple, small.
It is a simple question to which I am not able to find the answer:
Given a LaTeX command, how do I find out what package(s) it belongs to or comes from?
For example, given the \qquad horizontal spacing command, what package does it come from? Especially troublesome since it works without including any package!
Given a LaTeX command, how do I find out what package(s) it belongs to or comes from?
Consult your references:
If it's in the index to the TeXbook, it's inherited from TeX, the engine that drives LaTeX.
Otherwise, if it's in the index to the LaTeX manual, it's probably defined in latex.ltx or in one of the standard class files, not in a package.
Otherwise, if it's in the index to The LaTeX Companion, the page number probably tells you what package it's from.
Otherwise, you could do some fancy grepping on the results of find /usr/share/texmf -name '*.sty', but be prepared for a painful exercise.
Or, you could ask on http://stackoverflow.com. But then some idiot will respond by asking why you want to know...
You can search http://www.ctan.org/tex-archive/info/symbols/comprehensive/ for that information and more.
Remember that LaTeX is a macro language on top of TeX, and all the macros are made up of TeX which doesn't need to be imported. \qquad is in that category.
As far as I know, there is no really good general answer to this. But there are a number of techniques you might try for any given command. In the case of \qquad, it's part of basic TeX. Remember that you can always use TeX in interactive mode:
$ tex '\show\qquad'
This is TeX, Version 3.141592 (Web2C 7.5.6)
> \qquad=macro:
->\hskip 2em\relax .
\show\qquad
? x
No pages of output.
Some macros are added by LaTeX on top of TeX, such as \begin:
$ tex '\show\begin'
This is TeX, Version 3.141592 (Web2C 7.5.6)
> \begin=undefined.
\show\begin
? x
No pages of output.
whereas
$ latex '\show\begin'
This is pdfTeXk, Version 3.141592-1.40.3 (Web2C 7.5.6)
%&-line parsing enabled.
entering extended mode
LaTeX2e
Babel and hyphenation patterns for english, usenglishmax, dumylang, noh
yphenation, greek, monogreek, ancientgreek, ibycus, pinyin, loaded.
> \begin=macro:
#1->\#ifundefined {#1}{\def \reserved#a {\#latex#error {Environment #1 undefine
d}\#eha }}{\def \reserved#a {\def \#currenvir {#1}\edef \#currenvline {\on#line
}\csname #1\endcsname }}\#ignorefalse \begingroup \#endpefalse \reserved#a .
\show\begin
? x
No pages of output.
Everything else comes from packages. If you really wanna know which package a macro comes from (other than by google or grepping your texmf tree), you can check after each package you load whether it's defined. Try defining this before any \usepackage commands:
\let\oldusepackage\usepackage
\renewcommand\usepackage[1]{
\oldusepackage{#1}
\ifcsname includegraphics\endcsname
\message{^^Jincludegraphics is defined in #1^^J}
\let\usepackage\oldusepackage
\fi}
Then when you run latex on your .tex file, look for a line in the output that says includegraphics is defined in graphicx. It's not likely, but some devious packages might do bad things with \usepackage so there's a chance this might not work. Another alternative would be to simply define the command you're interested in before loading any packages:
\newcommand\includegraphics{}
Then you might get an error message when the package that defines the command is loading. This is actually less reliable than the former approach, since many packages use \def and \let to define their macros rather than \newcommand, bypassing the "already-defined" check. You could also just insert a check by hand in between each load: \ifcsname includegraphics\endcsname\message{^^Jdefined after graphicx^^J}\fi
Due to lack of reputation I cannot comment on Steve's answer, which was very helpful to me, but I would like to extend it a bit.
First, in his second approach (fiddling with usepackage) the case where usepackage has optional arguments is not dealt with. Secondly, packages are often loaded by other packages via RequirePackage which makes it hard to find the actual place of definition of a command. So my refinement of Steve's answer is:
\usepackage{xargs}
\let\oldusepackage\usepackage
\let\oldRequirePackage\RequirePackage
\renewcommandx{\usepackage}[3][1,3]{
\oldusepackage[#1]{#2}[#3]
\ifcsname includegraphics\endcsname
\message{^^Jincludegraphics is defined in #2^^J}
\let\usepackage\oldusepackage
\let\RequirePackage\oldRequirePackage
\fi}
\renewcommandx{\RequirePackage}[3][1,3]{
\oldRequirePackage[#1]{#2}[#3]
\ifcsname includegraphics\endcsname
\message{^^Jincludegraphics is defined in #2^^J}
\let\usepackage\oldusepackage
\let\RequirePackage\oldRequirePackage
\fi}
The xargs package is used here to get the unusual options of usepackage right (first and third parameter are optional).
Putting this directly after documentclass should tell where includegraphics is defined.