Easily find issues by searching: #<Issue ID>
Example: #1832
Easily find members by searching in: <username>, <first name> and <last name>.
Example: Search smith, will return results smith and adamsmith
hi fung, could you take a look at the commands in red. CommandLineOptions couldn't handle there options... let me know if you have any questions...
hi fung, could you take a look at the commands in red. CommandLineOptions couldn't handle there options... let me know if you have any questions...
> EchoCommand -->> Issues converting. -n Option is only an option if its the first argument. CommandLineOptions() cannot handling this scenerio.
We need to derive a class from CommandLineOptions() and overwrite some method(s) to handle the case where options always go before arguments. I can look into this when I have time, perhaps later on this week.
> HistoryCommand -->> Already modified by fung. Command has flaws. You can issue a "\history whatwhat blahblah thisshouldnotbevalidimput -c" and it will execute a clear history. This should throw an exception. We need to make sure to catch known command errors.
This is similar to the echo command, -c option needs to be specified first in order to handle the case 'history blah blah -c' (note that 'history -c blah blah' is a valid command on Linux).
> LsCommand -->> Issues converting. Options for ls can be combined in a single -[option] argument. example: -al... CommandLineOptions can only handle psuedo options as individuals.
I think we can derive a class from CommandLineOptions() to handle this, too.
> SourceCommand -->> Issues converting. CommandLineOptions can't understand if the options are arguments for the source file or for the source command.
If we were to implement a new class for echo and history, it seems to me that class can be used by source command as well.
> EchoCommand -->> Issues converting. -n Option is only an option if its the first argument. CommandLineOptions() cannot handling this scenerio.
We need to derive a class from CommandLineOptions() and overwrite some method(s) to handle the case where options always go before arguments. I can look into this when I have time, perhaps later on this week.
> HistoryCommand -->> Already modified by fung. Command has flaws. You can issue a "\history whatwhat blahblah thisshouldnotbevalidimput -c" and it will execute a clear history. This should throw an exception. We need to make sure to catch known command errors.
This is similar to the echo command, -c option needs to be specified first in order to handle the case 'history blah blah -c' (note that 'history -c blah blah' is a valid command on Linux).
> LsCommand -->> Issues converting. Options for ls can be combined in a single -[option] argument. example: -al... CommandLineOptions can only handle psuedo options as individuals.
I think we can derive a class from CommandLineOptions() to handle this, too.
> SourceCommand -->> Issues converting. CommandLineOptions can't understand if the options are arguments for the source file or for the source command.
If we were to implement a new class for echo and history, it seems to me that class can be used by source command as well.
(1) I made change in CommandLineOptions so that it would support command line parsing where options need to be specified before arguments. A new constructor has been added as:
public CommandLineOptions(String[] valueOptions, String[] pseudoOptions, boolean optionsBeforeArguments)
'history' command has been modified to use this new feature.
(2) For echo command, I think echo should just stay with its current implementation, this is because
> echo -n -x text
should echo back
-x text
if CommandLineOptions is involved, it would complain that -x is not a valid option.
(3) For ls command, there is another issue, #6613, that requests for supporting concatenation of short-form options.
(4) For source command, I am not quite sure what you were looking for. If you were asking for something like:
source -ss -e script -e aa -f bb cc
then I think the new CommandLineOptions should be able to support it.
(1) I made change in CommandLineOptions so that it would support command line parsing where options need to be specified before arguments. A new constructor has been added as:
public CommandLineOptions(String[] valueOptions, String[] pseudoOptions, boolean optionsBeforeArguments)
'history' command has been modified to use this new feature.
(2) For echo command, I think echo should just stay with its current implementation, this is because
> echo -n -x text
should echo back
-x text
if CommandLineOptions is involved, it would complain that -x is not a valid option.
(3) For ls command, there is another issue, #6613, that requests for supporting concatenation of short-form options.
(4) For source command, I am not quite sure what you were looking for. If you were asking for something like:
source -ss -e script -e aa -f bb cc
then I think the new CommandLineOptions should be able to support it.
Issue #6846 |
| Closed |
| Fixed |
| Resolved |
Completion |
| No due date |
| No fixed build |
| No time estimate |