Highlight a Specific Byte with gdb - debugging

I am checking assembly code of a program and would like to highlight a specific value:
gdb a.out
b main
run
s ... until where I want to focus my attention
x/32 0x555555554b80 display nicely the bytes
Now, is there a way to ask gdb to display the output AND highlight if a byte is equal to the desired value (here 0x27) ?
x/32 0x555555554b80 | 0x27
By highlighting I mean put this byte in bold or green, or whatever that makes it stands out!
PS: I am aware about this question but 1/ it does not answer my question, 2/ I would like to use gdb

There's no built-in way to do this. However, it can still be done with some scripting.
A relatively simple way, with a new-enough gdb, is to use the pipe command to pipe the output of x through a program that will do the highlighting you want. For example, GNU grep can colorize the match this way.
Other approaches are possible. For example you could write a new x-like command in Python, using gdb's Python API.

Related

How can I generate a list of every valid syntactic operator in Bash including input and output?

According to the Bash Reference Manual, the Bash scripting language is constituted of 4 distinct subclasses of syntactic elements:
built-in commands (alias, cd)
reserved words (if, function)
parameters and variables ($, IFS)
functions (abort, end-of-file - activated with keybindings such as Ctrl-d)
Apart from reading the manual, I became inherently curious if there was a programmatic way to list out or generate all such keywords, at least from one of the above categories. I think this could be useful in some contexts. Sometimes I wish I could see all the options available to me for what I can write in any given moment, and having that information as data, instead of a formatted manual, is convenient, focused, and can be edited, in case you want to strike out commands you know well, or that are too obscure for now.
My understanding is that Bash takes the input into stdin and passes it to the running shell process. When code is distributed in a production-ready form, it is compiled, so it runs faster. Unlike using a Python REPL, you don’t have access to the Bash source code from within Bash, so it is not a very direct route to write a program that searches through source files to find various defined commands. I mean that if you wanted to list all functions, Python has the dir() function which programmatically looks for function names in the namespace. But I don’t think Bash can do that. I think it doesn’t have a special syntax in its source files which makes it easy to find and identify all the keywords. Instead, they will be found if you simply enter them - like cd will “find” the program cd because $PATH returns the path to that command - but there’s no special way to discover them.
Or am I wrong? Technically, you could run a “brute force” search by generating every combination of symbols of every length and record when you did not get “error: unknown command” as a response.
Is there any other clever programmatic way to do this?
I mean I want to see a list of every symbol or string that the bash
compiler
Bash is not a compiler. It and every other shell I know are interpreters of various languages.
recognises and knows what to do with, including commands like
“ls” or just a symbol like “*”. I also want to see the inputs and
outputs for each symbol, i.e., some commands are executed in the shell
prompt by themselves, but what data type do they return?
All commands executed by the shell have an exit status, which is a number between 0 and 255. This is as close to a "return type" as you get. Many of them also produce idiosyncratic output to one or two streams (a standard output stream and a standard error stream) under some conditions, and many have other effects on the shell environment or operating environment.
And some
require a certain data type to standard input.
I can't think of a built-in utility whose expected input is well characterized as having a particular data type. That's not really a stream-oriented concept.
I want to do this just as a rigorous way to study the language.
If you want to rigorously study the language, then you should study its manual, where everything you describe has already been compiled. You might also want to study the POSIX shell command language manual for a slightly different perspective, which is more thorough in some areas, though what it documents differs in a few details from Bash's default behavior.
If you want to compile your own summary of Bash syntax and behavior, then those are the best source materials for such an effort.
You can get a list of all reserved words and syntactic elements of bash using this trick:
help -s '*' | cut -d: -f1
Or more accurately:
help -s \* | awk -F ': ' 'NR>2&&!/variables/{print $1}'

julia: static analyzer/linter for the command line

im looking for a shell command-line tool to lint julia scripts (a static analyzer), eg.
local:~ $ linter(myjuliascript.jl)
which will produce its output to terminal => text with linter results = either
// messages inlined with text of myjuliascript.jl or
...
...
// messages indicating line numbers of myjuliascript.jl
...
...
i found this, https://github.com/tonyhffong/Lint.jl, but it does not look promising (does not compile).
question: do you know of any good-quality command-line tool with which to lint julia scripts?
id rather avoid plugins to IDE's, since im a little tired of IDEs; often they are too much kung-fu-fighting with too little benefit. eg. tried to get the VS code julia linter working, no luck; VS code, julia linter doesn't work (on mac)
The closest thing currently available appears to be https://github.com/julia-vscode/StaticLint.jl. While you could technically call this from the command line if so desired using, julia -e, the interface would not seem to be very conducive to that sort of usage.

Code formatter / beautifier for bash (in command line)?

Looking for a command line code formatter that can be used for bash code. It must be configurable and preferably usable from command line.
I have a big project in bash, which I need to use Q in mind for. So far I am happy with a program written in python by Paul Lutus (a remake of his previous version in Ruby).
See http://arachnoid.com/python/beautify_bash_program.html (also cloned here https://github.com/ewiger/beautify_bash).
but I would like to learn any serious alternative to this tool if it exists. Requirements: it should provide robust enough performance and behavior of treating/parsing rather complicated code.
PS I believe full parsing of bash code is generally complicated because there exists no official language grammar (but please correct me if I am wrong about it).
You could give shfmt a try. It implements its own shell parser including Bash support, so it's more robust than plaintext-based tools.
And both the parser and printer are available as Go packages, so it should be easy to write a 20-line Go program to manipulate or play with shell code.
Please note that I'm the author, so the advice may be a bit biased :)
you can script vim to do: "gg=G" that means "indent all the file"
I discovered that the type builtin will print functions in a formatted manner.
#/usr/bin/env bash
source <(cat <(echo 'wrapper() {') - <(echo '}'));
type wrapper | tail -n +4 | head -n -1 | sed 's/^ //g'
https://github.com/bas080/flush
On the contrary the shell does have a rigorous grammar.
It is described both in English in the ISO standard and documentation for Bash and other shells, and in formal terms in the shell.y file in the Bash source tree.
What makes it "hard" is that where one normally thinks of, say, a quoted string as single lexical token, In the shell every meta character is a separate lexical token, so the meaning of a character can change depending on its grammatical context.
So the parsing tokens do not align with the "shell words" that a user thinks of, and a simple quoted string is at least 3 tokens.
The implementations typically take some shortcuts involving using multiple lexical analysers chosen by whether the grammar is inside quotes, inside numeric context, or outside both.

Formatting in Fortran 90/95

I am learning Fortran 90/95, and the book I am using had a discussion about the influence of line printers on the format statement. According to the book, the program uses the first character of the line to decide the line's position relative to the previous line (i.e. '1' starts a new page, '0' skips a line, '+' overwrites the previous line, and ' ' or any other character writes the new line below the previous line). I compiled and ran a simple program in the console to test this, but did not observe this behavior.
program test
integer :: i = 123
character(13) :: hello = 'Hello, World!'
100 format ('0','Count = ',I3)
write (*,*) hello
write (*,100) i
end program
The output is
Hello, World!
0Count = 123
where I would have expected
Hello, World!
Count = 123
Does anyone know why this is? Is this a legacy feature that is not used in Fortran 90/95? Is it specific behavior for a print to the console? I would like to know when (if ever) I need to declare a special first character in the format statement when writing.
My compiler is Force 2.0.9, which I believe is based on gfortran. I am running it on Windows 7, and the console is PowerShell.
Thanks for the help!
This was used in the 70s and even 80s with line printers in FORTRAN 77 and earlier ... but when did you last see a line printer? Any Fortran 90/95 book that teaches this feature should be thrown away.
This has already been answered on Stack Overflow: Are Fortran control characters (carriage control) still implemented in compilers?
This applies only to old "fixed form" Fortran (77 and earlier), not to the new "free form" Fortran (90 and later), when all commands had to be indented by 6 spaces. You can still use fixed-form with appropriate compiler flags. Sometimes this is even the default if the extension is .f rather than .f90.
Fortran 90/95 is much too recent for me, but I don't recall those formatting options from using FORTRAN in the seventies.
Nevertheless, I think it's a legacy feature, and the fact that you've got '+' to overwrite a line suggests the options are intended for output to a line printer not the console screen.
I am learning Fortran 90/95, and the book I am using had a discussion about the influence of line printers on the format statement. According to the book, the program uses the first character of the line to decide the line's position relative to the previous line (i.e. '1' starts a new page, '0' skips a line, '+' overwrites the previous line, and ' ' or any other character writes the new line below the previous line). I compiled and ran a simple program in the console to test this, but did not observe this behavior.
That is one of the legacy features of Fortran which is mostly ignored today, since (if nothing else) one does not print to printers directly. In any case, most compilers (I really couldn't say for gfortran specifically now, since I don't have it installed) have options to disregard that behaviour, and some of them ignore the first column by default. From what you've shown it is reasonable to assume your is one of them, so yes, you can ignore it.
Out of habit in regards to this practice, a lot of fortran programmers start any string with a blank or 1x in the write statement.

SWeave with non-R code chunks?

I often use Sweave to produce LaTeX documents where certain chunks are produced dynamically by executing R code. This works well - but is it also possible to have code chunks that are executed in different ways, e.g. by executing the code in the shell, or by running Perl, and so on? It would be helpful to be able to mix things up, so I could do things like run some shell commands to fetch some data, run some perl commands to pre-process it, and then run R commands to analyze it.
Of course I could use all R chunks and use system() as a poor-man's substitute, but that doesn't make for very pleasant reading in the document.
The new new thing (for multi-language, multi-format) docs may be dexy.it which for example these guys at opengamma.org use as the backend.
Ana, who is behind dexy, is also giving a lot of talks about it so also look at the dexy blog.
It's not directly related to Sweave, but org-babel, which is part of Emacs org-mode, allows to mix code chunks of different languages in one file, pass data from one chunk to another, execute them, and generate LaTeX or HTML export from the output.
You can find more informations about org-mode here :
http://www.orgmode.org/
And to see how org-babel works :
http://orgmode.org/worg/org-contrib/babel/
There is certainly no easy way to do this other than through either foreign language interfaces from R (maybe through inline if it's supported), or system(). For what it's worth, I would just use system(); that should be easy enough.
You can see this previous question about having a Sweave equivalent for Python, where one of the respondents actually creates a separate interface. This can give you a sense what what it would take to embed other languages which may not already be supported. At a minimum, you have to do major hacking on the Sweave driver.
Do you know emacs" org-mode and, more specifically, Babel? If you already know Emacs or are willing to switch to Emacs, then org-mode and Babel are the answer to your question(s).
For instance, I am currently working on a document which contains some shell-scripts, does computations with R and creates flow charts with dot (graphviz). Org-mode can export a variety of formats, e.g. LaTeX (that's what I use).
There is the StatWeave project which uses java rather than R to do the weaving, but will run multiple programs instead of just R. I don't know how hard it would be to get it to do Perl or other programs like that, but the homepage indicates that it already works with R, SAS, Stata, and others:
http://www.cs.uiowa.edu/~rlenth/StatWeave/

Resources