9

I just wanted to ask whether there is any command which would work on common shells (bash, dash, kornshell)? It is supposed to check if the line variable contains any part of the path.

if [[ $line =~ "$PWD"$ ]] ;then
Gilles 'SO- stop being evil'
  • 807,993
  • 194
  • 1,674
  • 2,175
applenic
  • 581
  • 3
  • 8
  • 21

2 Answers2

15

In any POSIX-compatible shell you can do:

case $line in (*"$PWD"*)
#    whatever your then block had
;;esac

This works in bash, dash, and just about any other shell you can name.

It can also be used to handle multiple possibilities easily. For example:

case $line in 
(*"$PWD"*)
    echo \$PWD match\!
;;
(*"$OLDPWD"*)
    echo \$OLDPWD match\!
;;
(*)
    ! echo no match\!
;;esac

You can also use alternation:

case $line in (*"$PWD"*|*"$OLDPWD"*)
    echo '$OLDPWD|$PWD match!'
;;esac

Note the use of quoting above:

  1. case $line ...
    • The object of a case statement will not be split on either $IFS or be used as a pattern for filename gen. This is similar to the way the left argument in a [[ test is treated.
  2. (*"$PWD"*)
    • Here also a shell expansion is not subjected to either $IFS or filename generation - an unquoted expansion will neither split nor glob.
    • But an unquoted expansion here might be construed as a pattern rather than a literal string though, and so an expansion might mean more than one thing depending on whether or not it is quoted.
    • It is important to quote any variable used in a pattern that should be literally interpreted, in the same way you would quote pattern chars which you wanted interpreted literally.
    • For example, if $PWD contained a * and was not quoted it would be construed as a pattern object and not as a literal * to be searched for.
mikeserv
  • 57,448
  • 9
  • 113
  • 229
  • @terdon - you were right - the `:` comment was confusing, but I used it because it didn't gen a syntax error or accidentally run some proggie named *whatever* in `$PATH`. This way will still gen a syntax error, but at least it's kinda clear that it should. – mikeserv Mar 29 '15 at 17:49
  • 2
    Note that if you need portability with the Bourne shell (for some ancient systems for instance), you need to drop the `(`: `case $line in *"$PWD"*)` – Stéphane Chazelas Mar 29 '15 at 21:35
  • @StéphaneChazelas - true, but if you do that, `zsh` chokes on it. – mikeserv Mar 30 '15 at 08:53
  • 1
    What do you mean? Are your referring to things like `$(case a in a);; esac)`? – Stéphane Chazelas Mar 30 '15 at 10:22
  • @StéphaneChazelas - I can't reproduce it, unless I do the command sub like in your example. It's weird too - `zsh -cx '(case $1 in $2*) echo ok;;esac)' -- one o` works, but prefixing a `: $` breaks it. I guess that's the problem I encountered in the past - it was always a little unclear, and I never looked at it too hard because adding the leftmost `(` always fixed it. Eventually I just wrote it off as some weird `zsh` thing and made it a rule to use both ends. – mikeserv Mar 30 '15 at 10:32
  • I prefer `()` as well as I like to have my braces matched, but it's still worth noting that Bourne compatibility implication. Note that `$(case a in a);;esac` issue used to be an issue in many shells (still is in pdksh (fixed in mksh) and ksh88 (fixed in ksh93)). I even believe it was the very reason to add support for the `case string in (pattern)` variant in the case syntax in ksh in the first place. – Stéphane Chazelas Mar 30 '15 at 10:50
  • @StéphaneChazelas - I don't doubt it. And it does make for easier reading - and I especially prefer it when generating `case` blocks for `eval` - in the latter case it is easy enough to get lost as is. And yes, the Bourne shell compatibility requirement is certainly noteworthy, but I think your comment sums it up well enough. Thanks again. I wonder if this particular issue w/ `zsh` actually is a consequence of its roots in `pdksh` - isn't that where it hails from originally anyway? It is based on some pre-93 `ksh` variant, I think. – mikeserv Mar 30 '15 at 10:55
  • No, zsh has nothing to do with pdksh or any ksh implementation (other than it has a ksh emulation mode). It was first released around the same time (89/90). It was once using readline for a wee while before it implemented its own line editor, but I don't think it's got any code in common with pdksh. – Stéphane Chazelas Mar 30 '15 at 11:21
  • @StéphaneChazelas - I know it's kinda weird, but will you look at [this](http://gdriv.es/mikeserv/scripts/printkey.sh.html)? I'm trying to bring this along to the point that I can do more w/ the information this provides than just print the bytes behind a keypress, but I'm confused about a couple of things. I think that, as is, it should handle multibyte sequences correctly - but I'm not sure my 7/8 byte buffer is enough. Also for whatever reason the only eight-bit *meta* *(whatever that means)* sequence that comes through is ALT+SPACE w/ octal 240. It's *a little* on topic... – mikeserv Mar 31 '15 at 12:12
4

Yes, recent versions of bash can do this:

$ pwd
/home/terdon
$ line="I'm in /home/terdon"
$ [[ "$line" =~ "$PWD"$ ]] && echo yes
yes

The same syntax works in zsh and ksh but not in dash. As far as I know, dash has no such capabilities.

Note that your regex is checking whether the variable $line ends with $PWD. To check if $PWD matches anywhere in $line, remove the $:

$ line="I'm in /home/terdon, are you?"
$ [[ "$line" =~ "$PWD" ]] && echo yes
yes
terdon
  • 234,489
  • 66
  • 447
  • 667
  • 1
    No, those only work in bash-3.2 and above provided the compat31 option has not been enabled or ksh93. It won't work properly in other bash versions or zsh if $PWD contains regular expression operators. – Stéphane Chazelas Mar 29 '15 at 21:34
  • @StéphaneChazelas yes, that's why I specified that _recent_ versions of bash can do this. As for the rest, I just tried it in `/home/terdon/foo` with `zsh`, `ksh` and `bash` (4.3.25) and it worked fine with all of them. It does indeed break when `PWD` contains regex operators. That had simply never occurred to me, thanks! – terdon Mar 29 '15 at 22:51