I am used to use what to find out some version string in my program, which is normal defined as a string in the c++ code, starting with "#(#)".
Now I cannot find it in Linux. Can anyone tell me what I am supposed to do? Thanks a lot!
The what command is part of the Source Code Control System (SCCS), which is not commonly available on Linux (if there is a Linux version at all). You can try to emulate it with the strings command:
strings a.out | fgrep '#(#)'
Reimplementations of what are available in CSSC (an SCCS-to-modern version control conversion package) and in BSD (source code).
try this
strings myprogram | grep '#('
As #larsmans said, what command is part of SCCS. Here is the link to the GNU replacement for SCCS
Additionally to the mention of SCCS, ident is the equivalent for RCS (and there are quite a few tools which use the same marker as RCS, CVS being the first one of these).
The following command gives most equivalent output compared to what
strings filename | grep -o \"\"#(#).*\"\" | sed 's/^\"#(#)//' | sed 's/\"$//'
Related
For some long errors, the gcc output is dense and has lots of line-wrapping etc. Especially when errors are subtle, it can take me 10-30 seconds of squinting to parse it with my eyes.
I've taken to pasting this in an open code-editor window to get some basic syntax highlighting and enable reformatting with regex's.
Has anyone invented a more automated method?
I use this script, called colorize:
#!/bin/bash
while read x ; do echo $x ; done \
| sed -e "s/.*error:.*/\x1b[1;36m&\x1b[0m/" \
-e "s/.*warning:.*/\x1b[1;36m&\x1b[0m/" \
-e "s/^\(.*\)\(required from\)/\x1b[1;36m\1\x1b[0mnote: \2/" \
-e "s/^\(.*\)\(In instantiation of\)/\x1b[1;36m\1\x1b[0mnote: \2/" \
-e "s/^\(.*\)\(In member\)/\x1b[1;36m\1\x1b[0mnote: \2/" \
| sed -e "s/error:/\x1b[1;31m&\x1b[1;36m/" \
-e "s/warning:/\x1b[1;35m&\x1b[1;36m/" \
-e "s/note:/\x1b[1;30m&\x1b[0m/"
Then I just call it like this(using make or whatever build system):
make |& colorize
And I get color output similar to clang.
I've found colorgcc to be invaluable. By introducing coloring, it becomes much easier to mentally parse the text of gcc error messages, especially when templates are involved.
If your errors are template related, take a look at STLfilt:
http://www.bdsoft.com/tools/stlfilt.html
gccfilter does coloring & simplification of messages.
http://www.mixtion.org/gccfilter/
If you use GCC 4.9, you can add -fdiagnostics-color=auto as an additonal compilation flag. At some later version, the color has been enabled by default.
check diagcc out, you can get something like this:
If your gcc ≥ 4.9, you can use argument -fdiagnostics-color=always.
To answer your question 4 years later, clang should be mentioned here.
Here's my current hack, which mostly inserts newlines and indentation in strategic locations along with a little extra annotation, but does nothing to address STL verbosity.
Note that as currently implemented, this script does not return an error if the compiler returned one, so doing something like this will not work properly: (make && ./runApplication). This could surely be remedied by someone with better bash-fu.
#!/bin/bash
# SUBSTITUTION RULES:
# Note: All substitution rules must end in a semi-colon, inside of the closing quote
subColonSpace='s/: /:\n /g;'
subSrc='s/^src/\nsrc/;'
subError='s/error:/error:\n\n======================================\nERROR:/;'
subWarning='s/ *error: *\n/ERROR: /;'
subWarning='s/ *warning: *\n/WARNING: /;'
subNote='s/note:/\n NOTE:/g;'
subOpenTic='s/‘/\n ‘/g;'
subOpenParen='s/(/(\n /g; s/(\n *)/()/g;'
subCommaSpace='s/, /,\n /g;'
# Note: The order of these may matter
sedExpr="$subColonSpace $subSrc $subError $subWarning $subNote $subOpenTic
$subOpenParen $subCommaSpace"
makelogFile=makelog.tmp
make "$#" 2>&1 | sed "$sedExpr" | tee $makelogFile
if you like Ruby there is GilCC! GilCC is very easy to install (just copy it to the bin folder) and easy to use (just type GilCC instead of "gcc" or "make") and it works with GCC version. Unlike Perl based scripts GilCC has statistics such as # of warnings and error and compile time. You don't have to mess with .bash files and it is cross platform as long as you can run Ruby on your machine. Since it has the power of Ruby; you can make GilCC do different things such as trigger test automation, unit test or program external hardware after a successful build.
Here is the link to the download page: http://www.onlysolutionssoftware.com/gilcc/
I'm trying to use SED to extract text from a log file. I can do a search-and-replace without too much trouble:
sed 's/foo/bar/' mylog.txt
However, I want to make the search case-insensitive. From what I've googled, it looks like appending i to the end of the command should work:
sed 's/foo/bar/i' mylog.txt
However, this gives me an error message:
sed: 1: "s/foo/bar/i": bad flag in substitute command: 'i'
What's going wrong here, and how do I fix it?
Update: Starting with macOS Big Sur (11.0), sed now does support the I flag for case-insensitive matching, so the command in the question should now work (BSD sed doesn't reporting its version, but you can go by the date at the bottom of the man page, which should be March 27, 2017 or more recent); a simple example:
# BSD sed on macOS Big Sur and above (and GNU sed, the default on Linux)
$ sed 's/ö/#/I' <<<'FÖO'
F#O # `I` matched the uppercase Ö correctly against its lowercase counterpart
Note: I (uppercase) is the documented form of the flag, but i works as well.
Similarly, starting with macOS Big Sur (11.0) awk now is locale-aware (awk --version should report 20200816 or more recent):
# BSD awk on macOS Big Sur and above (and GNU awk, the default on Linux)
$ awk 'tolower($0)' <<<'FÖO'
föo # non-ASCII character Ö was properly lowercased
The following applies to macOS up to Catalina (10.15):
To be clear: On macOS, sed - which is the BSD implementation - does NOT support case-insensitive matching - hard to believe, but true. The formerly accepted answer, which itself shows a GNU sed command, gained that status because of the perl-based solution mentioned in the comments.
To make that Perl solution work with foreign characters as well, via UTF-8, use something like:
perl -C -Mutf8 -pe 's/öœ/oo/i' <<< "FÖŒ" # -> "Foo"
-C turns on UTF-8 support for streams and files, assuming the current locale is UTF-8-based.
-Mutf8 tells Perl to interpret the source code as UTF-8 (in this case, the string passed to -pe) - this is the shorter equivalent of the more verbose -e 'use utf8;'.Thanks, Mark Reed
(Note that using awk is not an option either, as awk on macOS (i.e., BWK awk and BSD awk) appears to be completely unaware of locales altogether - its tolower() and toupper() functions ignore foreign characters (and sub() / gsub() don't have case-insensitivity flags to begin with).)
A note on the relationship of sed and awk to the POSIX standard:
BSD sed and awk limit their functionality mostly to what the POSIX sed and
POSIX awk specs mandate, whereas their GNU counterparts implement many more extensions.
Editor's note: This solution doesn't work on macOS (out of the box), because it only applies to GNU sed, whereas macOS comes with BSD sed.
Capitalize the 'I'.
sed 's/foo/bar/I' file
Another work-around for sed on Mac OS X is to install gsedfrom MacPorts or HomeBrew and then create the alias sed='gsed'.
If you are doing pattern matching first, e.g.,
/pattern/s/xx/yy/g
then you want to put the I after the pattern:
/pattern/Is/xx/yy/g
Example:
echo Fred | sed '/fred/Is//willma/g'
returns willma; without the I, it returns the string untouched (Fred).
The sed FAQ addresses the closely related case-insensitive search. It points out that a) many versions of sed support a flag for it and b) it's awkward to do in sed, you should rather use awk or Perl.
But to do it in POSIX sed, they suggest three options (adapted for substitution here):
Convert to uppercase and store original line in hold space; this won't work for substitutions, though, as the original content will be restored before printing, so it's only good for insert or adding lines based on a case-insensitive match.
Maybe the possibilities are limited to FOO, Foo and foo. These can be covered by
s/FOO/bar/;s/[Ff]oo/bar/
To search for all possible matches, one can use bracket expressions for each character:
s/[Ff][Oo][Oo]/bar/
The Mac version of sed seems a bit limited. One way to work around this is to use a linux container (via Docker) which has a useable version of sed:
cat your_file.txt | docker run -i busybox /bin/sed -r 's/[0-9]{4}/****/Ig'
Use following to replace all occurrences:
sed 's/foo/bar/gI' mylog.txt
I had a similar need, and came up with this:
this command to simply find all the files:
grep -i -l -r foo ./*
this one to exclude this_shell.sh (in case you put the command in a script called this_shell.sh), tee the output to the console to see what happened, and then use sed on each file name found to replace the text foo with bar:
grep -i -l -r --exclude "this_shell.sh" foo ./* | tee /dev/fd/2 | while read -r x; do sed -b -i 's/foo/bar/gi' "$x"; done
I chose this method, as I didn't like having all the timestamps changed for files not modified. feeding the grep result allows only the files with target text to be looked at (thus likely may improve performance / speed as well)
be sure to backup your files & test before using. May not work in some environments for files with embedded spaces. (?)
Following should be fine:
sed -i 's/foo/bar/gi' mylog.txt
I have two scripts which I would like to run both in a Linux machine and in a MacOS machine. But a different behaviour of the egrep command makes those scripts generate different outputs.
In particular, this is what happens when I use egrep on Linux (Ubuntu):
$ echo ".test" | egrep "[a-zA-Z0-9]*"
.test
$ echo ".test" | egrep -o "[a-zA-Z0-9]*"
test
$
and this is what happens when I use egrep on MacOS
$ echo ".test" | egrep "[a-zA-Z0-9]*"
.test
$ echo ".test" | egrep -o "[a-zA-Z0-9]*"
$
The first behaviour is what I would expect, the second one (empty output) is unexpected. Perhaps this is a bug in the implementation of egrep with -o option under MacOS?
Or, if the second behaviour is correct as well, do you know a way to obtain the same behaviour for the second case?
I tried to look at the corresponding man pages for the two commands, this is extracted from the Linux man page:
-o, --only-matching
Print only the matched (non-empty) parts of a matching line, with each
such part on a separate output line.
and this is extracted from the man page for MacOS:
-o, --only-matching
Prints only the matching part of the lines.
Although the descriptions seem a bit different, the meaning of the two options seems to be the same, so why is egrep -o behaving differently in MacOS? Am I not considering any subtle aspect of this command?
This depends on how the different grep implementations deal with empty matches ([a-zA-Z0-9]* matches the empty string).
I wrote a longer text about this over at Unix&Linux.
In short, should all empty matches be returned? There are infinitely many such matches.
I am writing a c++ code in my project that should tell whether my websphere mq server is running or not. In order to extract that we need to run "/opt/mqm/bin/amq status" to show whether it is running or not.Tricky thing is MQHOME=/opt/mqm is not constant across unix platforms.So,We agreed to a design to extract the MQHOME path from the absolute path of the process "amqzlaar0" which is an mq server process.So, we need to issue the below command that shows the process "amqzlaar0" along with its fullpath.Then,we will store the string in an array to extract MQHOME.
"ps -ef | grep amqzlaar0 | awk '{print $(NF-1)}' "
system() function is failing with exit code -1 when i use pipe symbol "|". But, if I issue just system("ps -ef"),it works.
Please help me on how to execute a pipe seperated command using system.
Your help is much appreciated.
Regards,
Sriram
I believe you should not run a command to check that amqzlaar0 is running, but query the proc(5) filesystem (on Linux).
Notice that /proc/ is not portable (e.g. not standardized in Posix). Some Unixes don't have it, and Solaris and Linux have very different /proc/ file systems.
If really want to run a command, use e.g. snprintf(3) to build the command (or std::string or std::ostringstream) then use popen(3) (and pclose) to run the command
Read Advanced Linux Programming to get a better view of Linux Programming. See also syscalls(2)
BTW, some people might have aliased e.g. grep (perhaps in their .bashrc), so you probably should put full paths in your command (so /bin/grep not grep etc...).
Just run ps -Ef. You're a C++ programmer. The equivalent of grep and awk is not hard in C++, and it's faster in C++ (doesn't require two additional processes)
For some long errors, the gcc output is dense and has lots of line-wrapping etc. Especially when errors are subtle, it can take me 10-30 seconds of squinting to parse it with my eyes.
I've taken to pasting this in an open code-editor window to get some basic syntax highlighting and enable reformatting with regex's.
Has anyone invented a more automated method?
I use this script, called colorize:
#!/bin/bash
while read x ; do echo $x ; done \
| sed -e "s/.*error:.*/\x1b[1;36m&\x1b[0m/" \
-e "s/.*warning:.*/\x1b[1;36m&\x1b[0m/" \
-e "s/^\(.*\)\(required from\)/\x1b[1;36m\1\x1b[0mnote: \2/" \
-e "s/^\(.*\)\(In instantiation of\)/\x1b[1;36m\1\x1b[0mnote: \2/" \
-e "s/^\(.*\)\(In member\)/\x1b[1;36m\1\x1b[0mnote: \2/" \
| sed -e "s/error:/\x1b[1;31m&\x1b[1;36m/" \
-e "s/warning:/\x1b[1;35m&\x1b[1;36m/" \
-e "s/note:/\x1b[1;30m&\x1b[0m/"
Then I just call it like this(using make or whatever build system):
make |& colorize
And I get color output similar to clang.
I've found colorgcc to be invaluable. By introducing coloring, it becomes much easier to mentally parse the text of gcc error messages, especially when templates are involved.
If your errors are template related, take a look at STLfilt:
http://www.bdsoft.com/tools/stlfilt.html
gccfilter does coloring & simplification of messages.
http://www.mixtion.org/gccfilter/
If you use GCC 4.9, you can add -fdiagnostics-color=auto as an additonal compilation flag. At some later version, the color has been enabled by default.
check diagcc out, you can get something like this:
If your gcc ≥ 4.9, you can use argument -fdiagnostics-color=always.
To answer your question 4 years later, clang should be mentioned here.
Here's my current hack, which mostly inserts newlines and indentation in strategic locations along with a little extra annotation, but does nothing to address STL verbosity.
Note that as currently implemented, this script does not return an error if the compiler returned one, so doing something like this will not work properly: (make && ./runApplication). This could surely be remedied by someone with better bash-fu.
#!/bin/bash
# SUBSTITUTION RULES:
# Note: All substitution rules must end in a semi-colon, inside of the closing quote
subColonSpace='s/: /:\n /g;'
subSrc='s/^src/\nsrc/;'
subError='s/error:/error:\n\n======================================\nERROR:/;'
subWarning='s/ *error: *\n/ERROR: /;'
subWarning='s/ *warning: *\n/WARNING: /;'
subNote='s/note:/\n NOTE:/g;'
subOpenTic='s/‘/\n ‘/g;'
subOpenParen='s/(/(\n /g; s/(\n *)/()/g;'
subCommaSpace='s/, /,\n /g;'
# Note: The order of these may matter
sedExpr="$subColonSpace $subSrc $subError $subWarning $subNote $subOpenTic
$subOpenParen $subCommaSpace"
makelogFile=makelog.tmp
make "$#" 2>&1 | sed "$sedExpr" | tee $makelogFile
if you like Ruby there is GilCC! GilCC is very easy to install (just copy it to the bin folder) and easy to use (just type GilCC instead of "gcc" or "make") and it works with GCC version. Unlike Perl based scripts GilCC has statistics such as # of warnings and error and compile time. You don't have to mess with .bash files and it is cross platform as long as you can run Ruby on your machine. Since it has the power of Ruby; you can make GilCC do different things such as trigger test automation, unit test or program external hardware after a successful build.
Here is the link to the download page: http://www.onlysolutionssoftware.com/gilcc/