[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: sed question



On 2019-12-07 at 04:43, Andrei POPESCU wrote:

> On Vi, 06 dec 19, 16:15:51, songbird wrote:
> 
>> The Wanderer wrote:
>>> 
>>> For example, 's/hello/newstring/' would be a valid sed
>>> 's'-expression, but 's/a/b/newstring/' would not; the former
>>> contains three instances of the delimiting token, which is valid,
>>> but the former contains four, which is not.
>>> 
>>> If you have the sed expression 's/${oldstring}/newstring/', and
>>> you define oldstring as having the value 'hello' then sed sees
>>> the first expression, and you get the good result.
>>> 
>>> But if you instead define oldstring as having the value 'a/b',
>>> then sed sees the second expression, and you get a syntax error.
>>> 
>>> 
>>> (Assuming I'm not mixing things up right now, anyway.)
>> 
>> :)  thank you for your reply.  now i see it.
> 
> One trick to avoid this problems is to use a different delimiter,
> e.g. '|'.

That doesn't actually avoid the problem; it just moves it. If the user
input includes the new delimiter, you have the same problem again.

This may still be useful in practice, since some delimiters are more
likely to be common in non-malicious input than others, but it just
reduces the likelihood of triggering the problem - it doesn't eliminate
it entirely.

> According to the manual[1][2] any other character is accepted.

Yep - using '/' is only a standard convention, it's not required. When
writing an s-expression which I know will be passed a path, I generally
use '@' myself; that A: is conveniently typable on the keyboard, B: is a
comparatively rare character to find in either path or filename, C:
doesn't have special meaning as part of a regular expression, and D:
unlike most of the other characters that fit the other criteria, isn't
treated specially by most shells that I know of.


`~!#$&*()={}|\;"'<> are all treated specially by bash, in at least some
circumstances. (Assuming I haven't mixed anything up.)

$^*()+[]|\.? are treated specially as part of a regular expression.

!%&()_+=-:;'",./? are comparatively common in paths and/or filenames.

As far as I can see, at least on my keyboard, that pretty much just
leaves @. It does still sometimes occur in paths and filenames, so it's
not really ideal, but it's probably less common there than any of the
non-special-meaning others.

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man.         -- George Bernard Shaw

Attachment: signature.asc
Description: OpenPGP digital signature


Reply to: