Minor dwm tip: start new terminal in secondary in same dir as master

A minor thing I figured out want to share. You are working furiously in your master terminal in dwm. Obviously you are miles into some deep folder structure. Now you need a new terminal, so you press alt-shift-enter, and a new one comes up. But it is in your home directory, so you have to cd to your old folder. I think this situation comes up often, and I was wondering how to make dwm persist pwd for new windows.
The trick is super simple, instead of alt-shift-enter, type “st” in your terminal. Since st persists pwd, you will get new terminal in your secondary in same pwd as your master. Hope this saves someone time. Thanks!

It’s not dwm or st related. It works that way in any DE/ WM and terminal you use. If you are in a directory and run a terminal (or any other stuff, like your file manager for instance) from there, it will spawn at that location. Try running thunar from a terminal in that directory, it will open thunar in that location.

Yes, you’re so right. Do you know how to do one thing: I have evince (the pdf viewer) set up to open in tag 2 using rules in config.h. However, when I do evince on terminal (using and alias, not sure if that matters), it does not open in tag 2, but in the same tag as a secondary window. Do you know how I can get that workflow also to open evince in tag 2?

Did you run xprop on it to get the exact class name? And how did you set the tag mask for evince?

No, I did not do either of these things. Will do those, and update in about 30 mins.

Get the exact class name with xprop and under ‘tag mask’ it should be 1 << 1 for it to spawn on tag 2.

Yes, tag mask is correct, however, I am not sure exact name w/ xprop, will update soon on that.

xprop says class name is either evince or Evince (I had evince). So my rule was correct in its syntax. However, it does not seem to apply if I write “evince main.pdf&” from terminal, using alias.
WM_CLASS(STRING) = “evince”, “Evince”
{ “evince”, NULL, NULL, 1 << 1, 0, -1 },

Actually, I tested, and it does not even work when launched with dmenu (somehow earlier I thought it did). In other words, no matter how I launch evince, it stays on the tag in which I launched it, not on tag 2 as the rules say it should.

The correct class name is the second one (“Evince”). I’ll log in dwm in a couple minutes and try it.

Well it works perfectly fine here.

/* class   		 instance	                  title   	  tags mask ...

{ "Evince", 		  NULL,      	   NULL,   		1 << 1, ...

Type Evince with a capital E in the class name and try it

1 Like

Hmm, indeed! The name is Evince, not evince (though xprop gave both options). It works now for me too after changing to E. Thank you Ji!
PS: Ji is in Hindi like san in japanese; if you don’t know a person’s name, but wish to address them (him or her) respectfully, you say Ji. Hence Ji :-).

Nice.
When you run xprop, the WM_CLASS line is (instance, class). So the class is always going to be the second one.
That’s why it wasn’t working. You ran xprop, got WM_CLASS(STRING) = “evince”, “Evince” and you were setting the class (which sould have been Evince) as the instance (whice was evince). It’s actually the same thing that was happening to firefox as you mentioned on the other post. xprop returns ‘firefox’ with a lower case F as the class, so that’s why Firefox with an upper case F wasn’t working.

1 Like

Ahh… much clearer now what was going on. Thanks for the explanation.