no backslash as first letter of an entry

OK, Thanks one more, I also look at this.

Thinking again about it I must admit that this bug report was rubbish. It is not the entry where ther mustn't be some kind of escape character, it's the Command Code right before the ?.

So this might be part of a function that lets me exclude some question marks from being interpreted as command marks.

Sorry! (But I still haven't seen any manpage.)

Thanks for your time.

About manpage - I also neved saw it :-). We must wait until it will be
published.

Hi again.

But what happens if any of these escape characters occurs right before the question mark ?

replace_cmnd=re.sub('\?', '{0['+str(ran)+']}', cmnd, count=1)

says that the escape character is replaced, doesn't it? Such a thing could happen in the command syntax of sed for example.

I today tested some cases:

cp /?
cp ?/
cp ?
c/p ?
c/np ?
cp /n ?

All working fine. If You mean something different, please reply.

You're right. Finally even I caught it. In '\?' there is ? which would be a special sign to python if not the \ made it escape its special function so that it can be looked after.

But wait. this also would mean that literally every ? is found. From this follows that there are no single character bash wildcards anymore und expressions which would at another place need an entry and it's sign "?" and therefore would have to ask for an entry. Because in this moment the wildcard is counted as an input command and the user would have to write the wildcard again into the input template.

Take e.g. the three-character-wildcard

rm junk.??? && find ?.txt

In the latter case both might be reasonable, i.e. wildcard or name input, but the first three question marks are clearly not meant as inputs, but you'll have to enter for example "? ? ? mybook" to remove all junks and to find mybook.txt. Right?

Program should allow to insert command with '?' inside. Ok, maybe /?
should mean '?' in command ?

Maybe. I don't know anything about coding, but I think there are a lot of ways to do this.

Maybe it could be one unequivocal killer-unique string to be attached in front of the ?. This could be done manually by the user or by CLIC after the user has marked the wildcards explicitely.

 /? seems a little too short to me, because again I cannot imagine all cases of reallife Bashcode containing this string!! Python could search for '739287679328734647700112197?'. When using the library from outside of CLIC you would just have to remove this unequivocal string. python should exclude these very wildcards and replace them by '?' in an additional condition right in the replace algorithm, - but not further handle them so that they might enter Bash.

 Another way would to remember the wildcard by the number of it's finding. Python is counting them already. Let the user mark them when the command is saved, count them and save their numbers into some file or even into the .clicompanion2

The question is how much CLI Companion might be extended into a wider operating agent, e. g. if call-by-argument might be implemented, so that recursively interlacing CLIC agents would work concurrently or successively. Not until then the question of runtime of some of the replace algorithms might become crucial. At the present state it's no matter of runtime or clever coding. but ... respice finem ....

Sorry If I am writing nonsense but I don't know much about computers.

Trying to play with this, I found a related (at least similar) bug https://bugs.launchpad.net/clicompanion/+bug/909542.

Yes, it's the same problem, now marked as duplicate, maybe we should use the user input field as the tag to replace?

For example:
command: ls -l filename
User Input: filename

So when executing the command filename gets replaced by the user input filename. So the User Input field now is used as a parameter specification instead of being a description.

Or maybe using user input column like this:
User Input: filename1: name of the first file, filename2: name of the second file

using a comma separated, semicolon separated tag: description tuples. (It's just a first approach).

This way we could also replace only the first occurrence of the key, so:

command: cat filename > filename
user input: filename: origin file, filename: destination file

can reuse the key words. That will make impossible to reuse the same keyword (like in sed -e 's/s_tosearch/prefix-s_tochange/g' filename), so maybe it isn't such a good idea.

I don't know if this is the same thing or not, but one problem I have noticed is that I can't add filesystem addresses with spaces in them, for example:

Imagine you want to search in a file called 'computer notes' with grep on the command line you would escape the space with a backslash like so:

grep grub ~/computer\ notes

If you add this address to the User Input box to replace a ? it will enter this at the command line:

grep grub ~/computer\

Which of course won't work.

I have tried it without the escape character and also encased in quote marks (both with and without the escape character) and I still can't get it to work.

Your right. I will move this comment as a current main description of the problem. Thank you!