-
Notifications
You must be signed in to change notification settings - Fork 1
Filter enhancements, syntax suggestions #26
Comments
Escaping is on the cards (need a way to get colon), but atm it's not supported, hence the three string types. Doubling up the quote will work with all types, so I see no reason to restrict it to one.
Not a fan of the syntax, looks more like 5 zeroes, not length of 5, pad with zero.
I was thinking of something like the Perl/Python-style
Heh, this goes against Carlos' new filters; I'm content how they are. I chose square brackets as that's what Take Command uses (not that I actually use it). Your syntax looks like it will trim the string
I do want something like that, but again, not sure of your syntax. I was thinking more of a sed-style
ATM padding and length are delayed and applied after all the other modifiers, so |
I didn't realize you could also quote with backtick or double quote when specifying a default. Is there any built in help for anything other than called
Not quite the same, though perhaps also useful. I was looking for a way of choosing the character (or string) used to pad a value to a particular length - a generalized form of zero padding that allows padding on either side, and with any string value. |
Not at the moment, but eventually.
Oh, yes. How about a more explicit |
That would be good, except I don't like separating the length from the pad string. They are part of the same operation, and chaining makes more sense when they are together. So any of the following make sense to me:
In all cases, the string is optional, with a default value of spaces. If this were implemented, then there is no need for the numeric left and right justification filter. My original suggestion was an attempt to preserve the terseness of the original syntax with augmented capability. |
I think I prefer the first (rather not use parentheses, as they might require escaping), having quotes optional (as a way to add ']'; the character-based options have it first, so escaping isn't required). Thus |
Some suggestions:
''
, For example!undefined;'This is Dave''s idea'!
!var;05!
would now be written as!var;5'0'
.A little more verbose, but now you can do something like
set "TOC=Chapter 1" & echo !TOC;-30' .'!
yieldingChapter 1. . . . . . . . . . .
'string'
syntax,!var;trim[xy]!
would become!var;trim'xy'!
.!var;'search'='replace'!
. In addition to providing case sensitive support, it would allow searching for=
and*
. Additional related extensions to consider!var;'search'i='replace'!
- case insensitive search, still useful because allows=
and*
'!var;'search'3='replace'!
- only replace the 3rd occurrence!var;'search'-1='replace'!
- only replace the last occurrence!var;*'search'='replace'!
- replace everything from beginning through 1st occurrence of search.!var;*'search'-1='replace'!
would replace from beginning through last occurrence, etc. No occurrence, occurrence of 0, and occurrence of 1 would all be equivalent.*
after 'search' to replace from search to end of string. For example!var;'search'*-1='replace'!
would replace from the last occurrence of search to the end of string.Lastly, I'm not sure if this is a bug or a feature request, but I would expect something like zero pad and right align to be chainable. For example,
set n=1 & echo !n;03;5!
should yield--001
, but I am getting----1
(I substituted dash for space). Note that with my proposed new syntax, the code would be written as!n;3'0';5!
.The text was updated successfully, but these errors were encountered: