Allow configuring comments

[rpavani1998]

Parsing a pattern argument
If an argument contains /*. then only the text before '/' is taken as the argument.
for example, if a/*.txt is the argument value given, then the command only takes 'a' as its argument.
use case: Filenames can't be globbed.

[tleonhardt]

@rpavani1998 Thank you for reporting an issue.

It would be helpful if you could provide some more information. In particular:

• Version of cmd2
• Version of Python
• Operating System

If you could also provide a minimal example that can reproduce the issue, that would be extremely helpful.

I attempted to quickly reproduce the issue on my system using the arg_print.py example and I was unable to reproduce the problem you report.

[tleonhardt]

I have tried reproducing this on Windows, macOS, and Linux using both Python 3.6 w/ cmd2 0.9.3 and Python 2.7 with cmd2 0.8.8 on each OS and was not able to reproduce it on any combination.

@rpavani1998 Please provide more info on the exact configuration you used when you encountered this issue.

[kotfu]

I think @rpavani1998's initial report is not quite correct. The problematic pattern is /*, not /.. Using arg_print.py try this (I did it on MacOS, Python 3.7, cmd2 master branch, behavior is likely the same on other OS and python versions, and any cmd2 version >= 0.9.0):

(cmd) aprint /my/path/*.txt
aprint was called with argument: '/my/path'
statement.raw = 'aprint /my/path/*.txt'
statement.argv = ['aprint', '/my/path']
statement.command = 'aprint'

As you can see, the perfectly reasonable file glob with the asterisk just after the slash is interpreted as the beginning of a C-style comment. When we switched parsing from pyparsing to a custom shlex-based parser, we retained backwards compatibility for comments, which meant that unclosed C-style comments are still interpreted as comments. The portion of the file glob that is the /* looks like the beginning of a C-style comment, so it gets stripped.

Options to resolve include:

• Have the user enter globbed paths in quotes. Comments inside quotes (either single or double) are not parsed as comments. i.e.:

  (Cmd) aprint '/my/path/*.txt'
  aprint was called with argument: "'/my/path/*.txt'"
  statement.raw = "aprint '/my/path/*.txt'"
  statement.argv = ['aprint', '/my/path/*.txt']
  statement.command = 'aprint'
  

• Only honor C-style comments if they are also closed properly, i.e. a /* followed by a */. This breaks backwards compatibility with prior cmd2 behavior, but is probably not a huge impact.
• Add some sort of instance attribute which allows a developer to say whether C-style comments are processed, or whether they are left alone (i.e. not interpreted as comments). The default for this instance attribute would be to honor C-style comments as comments, thus preserving the previous behavior unless someone intentionally wanted to change it.

[tleonhardt]

@kotfu Oh duh, the original issue text mentioned a problem with globbing, I should have thought of trying 'a/*txt' instead of 'a/.txt'! I can reproduce the problem now on master.

Prior to the 0.9.0 version, cmd2 parsed unclosed C-style comments so they were interpreted as glob patterns - i.e. it only honored C-style comments if they were closed properly.

If it isn't too difficult, then I think we should replicated this behavior in part for backwards compatibility and in part because it seems like a convenient way to handle this.

[kotfu]

Uhoh, I just made an oopsie :( I had a local branch with this change which was tracking master. When I pushed the change, it went to master. So no PR, because it's already been committed on master.

Sorry guys.

But I have fixed the issue by not treating C-style comments as comments unless they are closed properly, and have unit tests to verify correct behavior.

[rpavani1998]

oops! Sorry I have not seen the preview of the text. I have updated the comment now.

[rpavani1998]

Great! That works. Thanks! 👍 @tleonhardt @kotfu

[tleonhardt]

@kotfu As long as the unit tests pass on all OSes, which it looks like they do, then no harm.

I took a quick look at your commit and I think it looks OK.

Now just make sure you merge master into your existing PR branch and resolve the conflicts and we should be good to close this issue I think. Oh and update the ChangeLog in your PR with this bug fix if you would.