Forums Feature Suggestions $read with case sensitivity

Almost every thingy has it so far.

Would be very handy together with wildmask search.

You could use the r switch for a case-sensitive regex match.
That of course does mean you need to escape certain characters.

I know, i'm doing this right now.

Its just a feature request.

I think you missed 5618's point. He was pointing you to the -r switch, which is regex. And regex is case sensitive by design. I have to admit that switch is seldom used and thus it's uncommon.

And I think you are the one who missed something
As said it's just a suggestion

Thanks for connecting the dots, Mr. Wims.

I'm a little confused.. what's wrong with just using the regex switch? it seems to me like the conversion between wildcard and regex is trivial enough that it shouldn't really matter. IMO if there's already a reasonable way to achieve case sensitive searching that *works*, there's no real need to add another.

FWIW: a wildcard "*" becomes ".*", "?" becomes ".?" and "&" becomes "\S+" when translating to regex.

There was also no real need for $replacex() and it was added. It just makes things easier thats all.

Actually there was a need for $replacex because there was no way to use $replace when the production of one replacement matched the value of another replacement match later on in the string, ie:



It was not a "convenience" addition, it added functionality that was previously not available in that identifier. This is unlike $read, which can still be used by just changing the switch from w to r and modifying the search term slightly. The functionality of case sensitive $read is still available within the same identifier.

Secondly, what is your metric for defining "easier"? The only quantitative way I can think of is to count bytes, so let's do just that:

Here is the most common wildcard scenario of matching "*foo*":



Note that the regex version is also case sensitive. The second line looks "easier" to me, there, if "easy" is defined as "fewer bytes".

The other common scenario of matching foo* or *foo turns into:



They are equivalent in byte size, so I guess neither is easier-- aka: the regex is not harder.

And here is a much less common match like *foo*bar*:



The regex version is still one character shorter.

I'm not really buying that wildcard matching is any easier. Not only is the regex often shorter, but they are practically equivalent. How is the regex in any of the above examples complicated enough to warrant a new switch? Do you have a specific use case where wildcards can be considered significantly easier by any reasonable metric? If so, show an example. If you don't have a actual example of why you need this over using regex, I reiterate my confusion of why you're asking for something you have no use for.

As a sidenote, if you define "easier" as "I don't know how to write ridiculously simple regex expressions", you can always use the following short alias and continue writing wildcards:



Then use:



The first line is case insensitive (the ",i" switch), and the latter is case sensitive.

Regex is not something that a beginner scripter is going to understand even if it really doesn't take much to convert a search to compatible regex. Beginner scripters simply aren't going to have any idea how to do it. I think having a case sensitive switch for $read() could be useful. I very rarely do anything that uses case sensitivity, so would probably never use it myself, but I don't think that telling a new scripter to use regex is a good option for them either.

Well i solved that always by replacing the first replacement thing with something that won't appear inside the string then changing the rest and so on.

There WAS no real need for $replacex(). (for me at least and it was added because someone requested it or Khaled thought "would be nice to have".)
for example: as $replace performed the replacements after another, it was easy to bypass this problem.

Thats the same what you are trying to do now, using a "workaround".

I've just made a feature request thats all and now please stop complaining about it, i know how to use regex. As i already said before, i'm using regex at the moment for that, but it's easier for beginners or other (lazy) people.

Edit: As you can see from my example about the $replace thing, i don't care about longer or shorter scripts.

Sephiroth_, you obviously don't know the difference between $replace and $replacex. The behavior of $replace is to not ignore replacements that have already been made, $replacex doesn't do this.

will return zzcd

will return bzcd

I do.

If you do, then tell people what a "workaround" you've mentioned can be applied to your own example:
prints
prints

Well enough offtopic. :P
That was a response to this:


I know what it does.

No offense, and excuse me for being off-topic. What you've said about, and I quote, it was an irresponsible statement to make.

To summarize my thoughts on the various semi-random things that have been said so far:

• Yes, a case-sensitive search switch would be nice.
• No, the existence of regex search doesn't change that.
• $replace() is not an alternative to many uses of $replacex(). Intermediate substitution is often simply not practical.

Just maybe this thread can kinda stay on topic from here onwards.

Intermediate replacements using $replace() aren't really valid unless you know the input. It's fine to say $replace(hello,e,y,l,x,y,l) when you know the word is hello. Because you know that you can use y without complication because it's not in the word, intermediate replacement is a way to do the same thing that $replacex() does. However, if the word or phrase is unknown, you can't do this.

If $1 is hello, then this is true:

$replace($1,e,y,l,x,y,l) = $replacex($1,e,l,l,x)

However, if $1 is yes, then it is not true (the "y" will be different from one to the next).

You can use intermediary replacement using characters that are not expected within the unknown text and often that can work, but anytime you do not know 100% what the text will be, intermediary replacement is hit or miss. That is why $replacex() is very much needed.

IT WAS AN EXAMPLE, goddamn... xD

"?" would actually be "^.$" when used on its own, and ".", "^." or ".$" (depending on the position of the wildcard being middle, beginning or end of the string respectively) when used with other text to match. See for yourself:



As you can see, the wildcard ? does not always match where .? does.

Also, regex is fairly complex. It's almost like a small sub-language which you have to learn. A lot of people looking for basic string manipulation or comparison tools will not want to learn to use regex for simple tasks like this. Regex should be used for advanced string comparison and manipulation like it was intended.

Something as simple as a case-sensitive $read() flag really shouldn't get this much opposition imo, if only for consistency with other identifiers which support case-sensitivity. Seems like a good idea to me!