What you always can do is to encapsulate the weird symbols in regular expression brackets ([]
).
$ grep '[-][>]' file
This is what I would do in this case of the OP. There is a problem, the OP is now sure what the problem is, is it the hyphen (-
) or the greater-than sign (>
), encapsulate!
The problem here is, however, the hyphen. Hyphens generally signify a command/utility option. The utility grep
sees that one of its arguments starts with a hyphen, says "Hey, here comes an option, lets process it". It checks the option, sees >
, and says "Sorry, no can do!"
For reasons, like the above, the Posix standard introduced the double-hypen with the following requirement:
The requirement for recognizing --
is because conforming applications need a way to shield their operands from any arbitrary options that the implementation may provide as an extension. For example, if the standard utility foo
is listed as taking no options, and the application needed to give it a pathname with a leading <hyphen-minus>, it could safely do it as:
foo -- -myfile
and avoid any problems with -m
used as an extension.
source: POSIX.1-2017 Utility Description Defaults
Posix.1-2017 also makes this a guideline for when you write your own utilities:
Guideline 10: The first --
argument that is not an option-argument should be accepted as a delimiter indicating the end of options. Any following arguments should be treated as operands, even if they begin with the -
character.
source: POSIX.1-2017 Utility Syntax Guidelines
An implementation of this guideline can be seen in BashFAQ 035.
Hence, the true solution to the problem would have been:
$ grep -- '->' file