I am using LaTeX to write a pseudo algorithm using the algorithm package. I want to add comments on the code in a way that they get aligned. The following lines are what I could do, but the comments are not aligned. How do I do that?
\begin{algorithm}[H]
\caption{}
\label{}
\begin{tabbing}
quad \=\quad \=\quad \kill
\keyw{for} each a $\in$ A \keyw{do} \\
\> command; \qquad \qquad $\blacktriangleright$ add text here \\
\keyw{end} \\
\end{tabbing}
\end{algorithm}
The comments are like that:
one comment here\\
other here\\
other here\\
How do I align them?
If you're setting algorithms, use a dedicated pseudo code setting package. Here's one using algorithmicx's algpseudocode:
\documentclass{article}
\usepackage{algorithm,algpseudocode}
\algnewcommand{\algorithmicforeach}{\textbf{for each}}
\algdef{SE}[FOR]{ForEach}{EndForEach}[1]
{\algorithmicforeach\ #1\ \algorithmicdo}% \ForEach{#1}
{\algorithmicend\ \algorithmicforeach}% \EndForEach
\begin{document}
\begin{algorithm}
\caption{An algorithm}
\begin{algorithmic}[1]
\ForEach{$a \in A$}%
\State command \algorithmiccomment{This is a comment}
\State another command \algorithmiccomment{This is another comment}
\EndForEach
\end{algorithmic}
\end{algorithm}
\end{document}
algpseudocode already defines \ForAll. However, in the above code, I copied that definition into \ForEach. Comments can be added using \algorithmiccomment. Formatting and placement can be modified.
Apologies in advance for a rather simplistic question.
In a big pile of "note to self", I have this little awk one-liner that works perfectly for my needs, which is to remove comments from a php file. But I would like to better understand it:
awk '/^\/\*/{c++} c!=1; /^ \*\//{c++}'
I cannot, unfortunately, find the original post in order to better understand how it works.
Googling it turns up a ton of things on c++ but not the original post. Neither Explain Shell nor Symbol Hound has helped.
I don't particularly stumped by the {c++} c!=1; bit. Any help would be greatly appreciated.
I have tested your awk script and it does not work properly!!!
You should use the following one to remove :
gawk '/^\/\*/{c++} c!=1; /^.*\*\//{c=0}' php_file
to remove /* comments */ multi-lines comments or single lines with only /* comments */!!!
TESTED on:
In a nutshell,
awk will read the input file line by line and will do its default action: printing
when the condition /^\/\*/ is met ( /* comment that is directly located at the start of the line) the block {c++} will be executed!, in awk variable are by default initiated to 0, so after the block c=1 and c!=1 will be false so nothing will be printed.
as long as we are in the comment section c!=1 will be false so nothing will be printed.
then we reach the last line of comment and c is set back to 0, so from the following line everything will be printed again.
REMARK:
lines with commands followed /* */ are still printed as-is
// comments are not removed
If there are some super important commands on the same line directly following a comment block they will be lost!!!
/* comment starts
/* still some comments
end of comments */some super important commands;
IMPROVEMENT:
change c=!1 by c<1 to improve the stability of the script, with c!=1 your script will stop functioning properly in the case:
/* comment starts
/* still some comments
end of comments */
I have recently started studying shell script and I'd like to be able to comment out a set of lines in a shell script. I mean like it is in case of C/Java :
/* comment1
comment2
comment3
*/`
How could I do that?
Use : ' to open and ' to close.
For example:
: '
This is a
very neat comment
in bash
'
Multiline comment in bash
: <<'END_COMMENT'
This is a heredoc (<<) redirected to a NOP command (:).
The single quotes around END_COMMENT are important,
because it disables variable resolving and command resolving
within these lines. Without the single-quotes around END_COMMENT,
the following two $() `` commands would get executed:
$(gibberish command)
`rm -fr mydir`
comment1
comment2
comment3
END_COMMENT
Note: I updated this answer based on comments and other answers, so comments prior to May 22nd 2020 may no longer apply. Also I noticed today that some IDE's like VS Code and PyCharm do not recognize a HEREDOC marker that contains spaces, whereas bash has no problem with it, so I'm updating this answer again.
Bash does not provide a builtin syntax for multi-line comment but there are hacks using existing bash syntax that "happen to work now".
Personally I think the simplest (ie least noisy, least weird, easiest to type, most explicit) is to use a quoted HEREDOC, but make it obvious what you are doing, and use the same HEREDOC marker everywhere:
<<'###BLOCK-COMMENT'
line 1
line 2
line 3
line 4
###BLOCK-COMMENT
Single-quoting the HEREDOC marker avoids some shell parsing side-effects, such as weird subsitutions that would cause crash or output, and even parsing of the marker itself. So the single-quotes give you more freedom on the open-close comment marker.
For example the following uses a triple hash which kind of suggests multi-line comment in bash. This would crash the script if the single quotes were absent. Even if you remove ###, the FOO{} would crash the script (or cause bad substitution to be printed if no set -e) if it weren't for the single quotes:
set -e
<<'###BLOCK-COMMENT'
something something ${FOO{}} something
more comment
###BLOCK-COMMENT
ls
You could of course just use
set -e
<<'###'
something something ${FOO{}} something
more comment
###
ls
but the intent of this is definitely less clear to a reader unfamiliar with this trickery.
Note my original answer used '### BLOCK COMMENT', which is fine if you use vanilla vi/vim but today I noticed that PyCharm and VS Code don't recognize the closing marker if it has spaces.
Nowadays any good editor allows you to press ctrl-/ or similar, to un/comment the selection. Everyone definitely understands this:
# something something ${FOO{}} something
# more comment
# yet another line of comment
although admittedly, this is not nearly as convenient as the block comment above if you want to re-fill your paragraphs.
There are surely other techniques, but there doesn't seem to be a "conventional" way to do it. It would be nice if ###> and ###< could be added to bash to indicate start and end of comment block, seems like it could be pretty straightforward.
After reading the other answers here I came up with the below, which IMHO makes it really clear it's a comment. Especially suitable for in-script usage info:
<< ////
Usage:
This script launches a spaceship to the moon. It's doing so by
leveraging the power of the Fifth Element, AKA Leeloo.
Will only work if you're Bruce Willis or a relative of Milla Jovovich.
////
As a programmer, the sequence of slashes immediately registers in my brain as a comment (even though slashes are normally used for line comments).
Of course, "////" is just a string; the number of slashes in the prefix and the suffix must be equal.
I tried the chosen answer, but found when I ran a shell script having it, the whole thing was getting printed to screen (similar to how jupyter notebooks print out everything in '''xx''' quotes) and there was an error message at end. It wasn't doing anything, but: scary. Then I realised while editing it that single-quotes can span multiple lines. So.. lets just assign the block to a variable.
x='
echo "these lines will all become comments."
echo "just make sure you don_t use single-quotes!"
ls -l
date
'
what's your opinion on this one?
function giveitauniquename()
{
so this is a comment
echo "there's no need to further escape apostrophes/etc if you are commenting your code this way"
the drawback is it will be stored in memory as a function as long as your script runs unless you explicitly unset it
only valid-ish bash allowed inside for instance these would not work without the "pound" signs:
1, for #((
2, this #wouldn't work either
function giveitadifferentuniquename()
{
echo nestable
}
}
Here's how I do multiline comments in bash.
This mechanism has two advantages that I appreciate. One is that comments can be nested. The other is that blocks can be enabled by simply commenting out the initiating line.
#!/bin/bash
# : <<'####.block.A'
echo "foo {" 1>&2
fn data1
echo "foo }" 1>&2
: <<'####.block.B'
fn data2 || exit
exit 1
####.block.B
echo "can't happen" 1>&2
####.block.A
In the example above the "B" block is commented out, but the parts of the "A" block that are not the "B" block are not commented out.
Running that example will produce this output:
foo {
./example: line 5: fn: command not found
foo }
can't happen
Simple solution, not much smart:
Temporarily block a part of a script:
if false; then
while you respect syntax a bit, please
do write here (almost) whatever you want.
but when you are
done # write
fi
A bit sophisticated version:
time_of_debug=false # Let's set this variable at the beginning of a script
if $time_of_debug; then # in a middle of the script
echo I keep this code aside until there is the time of debug!
fi
in plain bash
to comment out
a block of code
i do
:||{
block
of code
}
I am using python-sphinx for documenting a C code. I am not interested in features offered by doxygen, however I sometime would like to include some snippets from the code-base.
The .. literalinclude:: looks great, but the :lines: option is a bit weak especially if the code is edited afterwards.
I am thinking about a new option such as :marker-start: <<<HERE and :marker-end: <<<END.
What would be the easiest way to achieve this behavior?
You can use the start-after and end-before options. Below is an example.
example.txt:
# START
first line
second line
# END
third line
Markup:
.. literalinclude:: example.txt
:start-after: # START
:end-before: # END
This will appear in the output:
first line
second line
See https://www.sphinx-doc.org/en/master/usage/restructuredtext/directives.html#directive-literalinclude.
The following code is something I am beginning to test for use within a "Texas Hold Em" style game I am working on.
My question is why, when running the following code, does the puts involving a "♥" return a "\u" in it's place. I feel certain it is this multibyte character that is causing the issue becuse on the second puts , I replaced the ♦ with a d in the array of strings and it returned what i was expecting. See Below:
My Code:
#! /usr/bin/env ruby
# encoding: utf-8
table_cards = ["|2♥|", "|8♥|", "|6d|", "|6♣|", "|Q♠|"]
# Array of cards
player_1_face_1 = "8"
player_1_suit_1 = "♦"
# Player 1's face and suit of first card he has
player_1_face_2 = "6"
player_1_suit_2 = "♥"
# Player 1's face and suit of second card he has
test_str_1 = /(\D8\D{2})/.match(table_cards.to_s)
# EX: Searching for match between face values on (player 1's |8♦|) and the |8♥| on the table
test_str_2 = /(\D6\D{2})/.match(table_cards.to_s)
# EX: Searching for match between face values on (player 1's |6♥|) and the |6d| on the table
puts "#{test_str_1}"
puts "#{test_str_2}"
Puts to Screen:
|8\u
|6d|
-- My goal would be to get the first puts to return: |8♥|
I am not so much looking for a solution to this (there may not even be one) but more so a "as simple as possible" explanation of what is causing this issue and why. Thanks ahead of time for any information on what is happening here and how I can tackle the goal.
The "\u" you're seeing is the Unicode string indicator.
For example, Unicode character 'HEAVY BLACK HEART' (U+2764) can be printed as "\u2764".
A friendly Unicode character listing site is http://unicode-table.com/en/sets/
Are you able to launch interactive Ruby in your shell and print a heart like this?
irb
irb> puts "\u2764"
❤
When I run your code in my Ruby, I get the answer you expect:
test_str_1 = /(\D8\D{2})/.match(table_cards.to_s)
=> #<MatchData "|8♥|" 1:"|8♥|">
What happens if you try a regex that is more specific to your cards?
test_str_1 = /(\|8[♥♦♣♠]\|)/.match(table_cards.to_s)
In your example output, you're not seeing the Unicode heart symbol as you want. Instead, your output is printing the "\u" which is the Unicode starter, but then not printing the rest of the expected string which is "2764".
See the comment by the Tin Man that describes encoding for your console. If he's correct, then I expect the more-specific regex will succeed, but still print the wrong output.
See the comment by David Knipe that says it looks like it gets truncated because the regex only matches 4 characters. If he's correct, then I expect the more-specific regex will succeed and also print the right output.
(The rest of this answer is typical for Unix; if you're on Windows, ignore the rest here...)
To show your system language settings, try this in your shell:
echo $LC_ALL
echo $LC_CTYPE
If they are not "UTF-8" or something like that, try this in your shell:
export LC_ALL=en_US.UTF-8
export LC_CTYPE=en_US.UTF-8
Then re-run your code -- be sure to use the same shell.
If this works, and you want to make this permanent, one way is to add these here:
# /etc/environment
LC_ALL=en_US.UTF-8
LC_CTYPE=en_US.UTF-8
Then source that file from your .bashrc or .zshrc or whatever shell startup file you use.