I am debugging a piece of code which has complex data structures in it. I want to use dbx variables to hold the values of these structures to avoid pointer indirection every time to see the contents.
When I do, something like set $myTemp=*ptr->curValue, it does not give any error, but issuing a display command does not show up myTemp. Also when I execute print $myTemp, I get no output and no error either. Doing print myTemp(without dollar sign) gives error which goes like "myTemp not defined in local scope ..". Any ideas what could be wrong here.
I am using solaris 10 here.
You don't have to use set in dbx. You can just specify the variablename=thevalue, also no spaces. Otherwise it gets all honked up.
I think you have a syntax error. Dbx uses the ksh shell syntax and you are using a dollar sign prefix on the name of the variable (according to your description).
Instead of saying:
set $foo=bar
say this:
set foo=bar
Related
I found in all make warning / error messages, it uses a single back quote but then a single quote to highlight the user input.
For example, the error message of the undefined makefile name is like
Makefile `xxx' was not found.
At first I thought it was a typo, but it seems to me it is intended for all messages.
https://www.gnu.org/software/make/manual/html_node/Error-Messages.html
It is distinct from the modern development to use both single / double quote around the highlight text, e.g. Makefile 'xxx' was not found.
Does anyone know the reason behind it?
I would guess it is a holdover from when fonts were displayed differently. For computer text that was intended to be read by humans, it used to be that (on many systems) using backquote/quote would produce output that resembles the way that English was normally typeset.
Consider for example: https://data.historicaltexts.jisc.ac.uk/view?pubId=bl-001973110&pageId=bl-001973110-660536-22 :
For other information, see for example:
discussion of "backtick-apostrophe" notation
Markus Kuhn's explanation of how the X Window System displayed fonts
I'm currently an intern that's out of their depths here, this is really my first time using Linux, and everything I know comes from basic level tutorials.
I was asked by my boss today to install a program, and I'm following this tutorial on it, but am stuck at the Path part of it.
Solved
Every time I try to do this:
~$ export DTITK_ROOT=${autofs/cluster/name/MyUsername/more/path/DTI-TK/dtitk-2.3.1-Linux-x86-64}/dtitk
Like it told me to.
I get:
bash: DTITK_ROOT=${autofs/cluster/name/MyUsername/more/path/DTI-TK/dtitk-2.3.1-Linux-x86-64}/dtitk: bad substitution
Thank you user Muon
In bash, the ${} syntax can be used to substitute in the value of a previously defined variable, and you've enclosed an explicitly typed-out path within it, so bash is looking for a variable called path/MyUsername/more/path/DTI-TK/dtitk-2.3.1-Linux-x86-64 and not finding it. It should work if you run the command without the substitution:
$ export DTITK_ROOT=/path/to/dtitk
I'm sure this is one of the dumbest problems asked on this site, but I am very new to linux, and a little out of my depths. I'm working off of this tutorial here and am stuck on the "add the path" and verify steps.
For this one the tutorial told me to use this:
export PATH=${PATH}:${DTITK_ROOT}/bin:${DTITK_ROOT}/utilities:${DTITK_ROOT}/scripts
I have already defined DTITK_ROOT, and have a few questions about the above instructions.
Should the ${} be left around the DTITK_ROOT?
My DTITK_ROOT is the full path (I think that's the right term) to the file I extracted the program to, should I change that?
What do I write for ${PATH} in that case? I understand that I'm supposed to replace it with something, but I don't know what. Everything I've tried doesn't pass the verify step.
I'm sorry if it seems like a dumb or really simple question, but I don't even know any keywords to google in order to find how to get the answer.
Yes. This is how you access the path stored in DTITK_ROOT. This is called parameter expansion. You can read more about it here.
No, don't change anything. Also, a more commonly used term is absolute path, in comparison to relative path. The absolute path is a path from the root directory, /. Relative path is a path from your current working directory. You can read more about paths in general and the difference between absolute and relative paths here.
You don't replace it with anything. Once again, parameter expansion comes into play and this will be replaced with what is already stored in your path variable. So really all this command is doing is taking your path variable, adding some more paths to it, and then storing it back into your path variable. If you didn't know, the path variable contains paths to all executable files that you would like to execute without typing the full path. Here is a good discussion on path variables, along with other environment variables.
1st command takes care of path
export DTITK_ROOT=mypathonSystem/dtitk
2nd command
export PATH=${PATH}:${DTITK_ROOT}/bin:${DTITK_ROOT}/utilities:${DTITK_ROOT}/scripts
I am not too sure but I think second command should run as is since you defined DDTITK_ROOT in first command
${PATH} is letting the system know where the resources can be found at
have you tried running first command, then running second command unmodified?
Should the ${} be left around the DTITK_ROOT?
Yes. In the case of the shell, it is not essential here because the / that follows the $DTITK_ROOT is enough to signal that we have reached the end of the variable name, but doing ${DTITK_ROOT} explicitly says that the variable name is DTITK_ROOT and not that plus whatever characters might be on the end of it. Other programs (such as make) which allow you to write shell commands to execute might not be so accommodating - make would think that $DTITK_ROOT would be the value of $D followed by the literal characters TITK_ROOT. So, it is a good practice to just get used to putting {} around shell variable names that are longer than a single character.
My DTITK_ROOT is the full path to the file I extracted the program to, should I change that?
If you mean the full path to the directory that you extracted the program to, then that is what you should use. I am assuming that you have something like "export DTITK_ROOT=/Users/huiz/unix/dtitk" (per the example).
On thing you can do is to verify that the value of DTITK_ROOT is available by executing a "echo ${DTITK_ROOT}" to verify that it has the proper value.
I am working on a bash prompt project which acts upon different states in the directory you are currently in.
What I need now is a way to load a mini configuration from the current directory, which is easily done with . .params.conf, except that this method is extremely unsecure, as anyone with write access to the directory you are in can create and execute command as you when you stumble upon a directory with a .params.conf file in it.
What is the best way of loading variables from a file like this?
The variables is going to be mostly in a true/false state, so I am not parsing them in any way so it can be executed.
Possible solutions:
A loop, loading each predefined variable is a possible, but I want to keep the code in a readable fashion.
Put the whole file in an bash array would be the best solution, but how can I populate a key/value dict in bash like this?
If bash can source a file only loading the variables..
I dont know how the format of the params.conf file will look like yet. But I think the easiest would be one line for each param, separated by space. Like one of this on each line: key value that can have space in it.
eval can be very insecure and can still execute malicious code. It's better to use declare:
while read varname value
do
declare "$varname=$value"
done < .params.conf
If your values do not contain quotes, it is rather easy:
while read varname value ; do
eval $varname="'$value'"
done < .params.conf
If there are quotes inside of the variables, you have to be more careful and add some escaping.
How can you set a string to be used instead of standard input? For example, when running the latex command in Unix it will always find some trivial errors, to skip through all errors you have to enter "r" into the command line (I now know that with latex specifically you can use -interactionmode nonstopmode, but is there a more general solution to do this?)
Is there anyway to specify that this should be done automatically? I tried redirecting standard input to read from a file containing "r\n", but this didn't work.
How can I achieve this?
Not all applications that need input can be satisfied with their stdin redirected.
This is because the app can call the isatty C function (if written in C, or some equivalent call for other languages) to determine if the input come from a tty or not.
In such situation, there is a valuable tool to use, and this is expect.
latex --interaction=MODE
where MODE is one of:
errorstopmode: stop at every error and ask for input
scrollmode: scroll over non-fatal errors, but stop at fatal errors (such as "file not found")
nonstopmode: scroll over non-fatal errors, abort at fatal errors
batchmode: like nonstopmode, but don't show messaes at the terminal
For interactive use, errorstopmode (the default) is fine, for non-interactive use, nonstopmode and batchmode are better.
But beware, there are no trivial errors: all errors must be fixed, and all warnings should be fixed if possible.
Redirecting stdin works without problems here:
/tmp $ tex '\undefined\end' <<< r
This is TeX, Version 3.1415926 (TeX Live 2010)
! Undefined control sequence.
<*> \undefined
\end
? OK, entering \nonstopmode...
(see the transcript file for additional information)
No pages of output.
Transcript written on texput.log.
You've got two plausible answers detailing the way to handle Latex specifically. One comment indicates that you need a more general answer.
Most usually, the tool recommended for the general solution is 'expect'. It arranges for the command to have a pseudo-tty connected for input and output, and the command interacts with the pseudo-tty just as it would your real terminal. You tell 'expect' to send certain strings and expect certain other strings, with conditional code and regular expressions to help you do so.
Expect is built using Tcl/Tk. There are alternative implementations for other languages; Perl has an Expect module, for example.
From the man page:
-interaction mode
Sets the interaction mode. The mode can be either batchmode, nonstopmode, scrollmode, and errorstopmode. The meaning of these modes is the same as that of the corresponding \commands.
Looks like -interaction nonstopmode might help you.