Package Details: st-git 0.8.3.r19.g9ba7ecf-1

Git Clone URL: (read-only, click to copy)
Package Base: st-git
Description: A simple virtual terminal emulator for X.
Upstream URL:
Licenses: MIT
Conflicts: st
Provides: st
Submitter: vesath
Maintainer: shoober420
Last Packager: shoober420
Votes: 51
Popularity: 0.000001
First Submitted: 2012-11-30 01:40 (UTC)
Last Updated: 2020-06-05 03:45 (UTC)

Required by (4)

Sources (3)

Pinned Comments

Latest Comments

vonbloom commented on 2021-05-18 13:34 (UTC) (edited on 2021-05-18 13:41 (UTC) by vonbloom)

echo 'Applying patches from $_startdir if they exist...'

This is not going to print $_startdir value. Either replace single quotes by double quotes or concatenate the variable value between the literal string 'Applying patches from '"$_startdir"' if they exist...'

patch -p1 -s -i "$patch"

This is not going to apply any patch, you need to pass the path where the source code is patch -d "$_sourcedir" -p1 -s -i "$patch"

shoober420 commented on 2020-06-05 03:47 (UTC)


Thank you, fixed.

galunid commented on 2020-06-04 06:45 (UTC) (edited on 2020-06-04 06:45 (UTC) by galunid)

if [ -d "$_startdir}/patches" ]; then

it has unnecessary "}", thus prevents your PKGBUILD from applying patches

Static_Rocket commented on 2020-05-23 17:43 (UTC)

@shoober420 cool, thanks. Just a heads up: _gitname, _sourcedir, and _gitdir all store the same information. _gitdir is just a variable I created to store the contents of the pkgname variable with "-git" removed. This is just what I use for git pkgbuilds that have a similar name.

Alternatively you could do away with these variables and tell git to download the project into a directory with the same name as the pkgname with this modification to the source variable


shoober420 commented on 2020-05-23 13:13 (UTC)

@Static_Rocket Updated and added you to the list of contributors, thank you.

Static_Rocket commented on 2020-05-19 01:17 (UTC) (edited on 2020-05-19 01:32 (UTC) by Static_Rocket)

Alright, well I've made some changes since then. This one is a little cleaner than the one I originally linked:

(Mind throwing my name in there somewhere?)

shoober420 commented on 2020-05-13 16:55 (UTC) (edited on 2020-05-13 16:57 (UTC) by shoober420)

Whoops, I uploaded your patch @Static_Rocket. I myself would include the scrollback patch as optional, but it has broke compiling for me in the past.

shoober420 commented on 2020-05-11 17:41 (UTC)

Updated, sorry for the wait.

Static_Rocket commented on 2020-04-14 21:33 (UTC)

@shoober420 I would be honored but I'm not entirely sure the autopatcher is actually useful for a git based package. As the git package grabs the source, the new patches must be fetched manually and have a higher likelihood of breaking. I thought about using the reset in the prepare to keep it locked to a user specified version but then this would make the pkgver script wrong and defeat the purpose of syncing with the git source. I was just goofing around and didn't feel like patching it manually when I was testing.

shoober420 commented on 2020-04-05 16:07 (UTC)

I have been quite busy, my apologize.

Would you like to co-maintain @Static_Rocket?

Static_Rocket commented on 2020-02-25 06:31 (UTC)

Liked the PKGBUILD but was a little bummed when I noticed it made adding patches a little more difficult. Made an autopatcher to simplify the process a bit. Let me know if there are any improvements I could make to this.

actionless commented on 2020-01-26 06:06 (UTC)


This contains the absolute path to the directory where the PKGBUILD is located, which is usually the output of $(pwd) when makepkg is started. Use of this variable is deprecated and strongly discouraged.

shoober420 commented on 2019-11-06 08:02 (UTC)

I found time to update this, but just stumbled upon your post after updating. I’ll have a look at your PKGBUILD and adjust accordingly. Thank you good sir!

waschtl commented on 2019-10-30 22:56 (UTC) (edited on 2019-10-30 22:59 (UTC) by waschtl)

Active maintainership on this package is great news. I recently started working on a couple issues with the aur/st package:

  • making the configuration via config.h visible to the user
  • making working terminfo entries available in the package

Feel free to have a look at my solutions and copy them or improve upon them as you please.

shoober420 commented on 2019-10-30 03:19 (UTC)

Love this terminal, I’ll maintain this package. Give me a day or two and I’ll have a working PKGBUILD.

BurhanDanger commented on 2017-10-01 05:37 (UTC)

I have one st build with easy changeable colorscheme, check that out also.

buttcake commented on 2017-04-08 16:45 (UTC) Can someone please take a look and tell me what I'm doing wrong ?

Aelius commented on 2016-10-25 17:39 (UTC)

I have a few questions/comments about this package #1: You remove the terminfo file; but st-git needs its terminfo. The one packaged with current ncurses does not work with st-git. We need to install that terminfo somewhere. #2 Your various FLAGS alterations should probably be submitted upstream, not here, no? However, it looks like they were all implemented by now, with the exception of CPPFLAGS, and I assume they did that for a reason. You can take those out of the PKGBUILD. #3 While we're taking things out of the PKGBUILD, your personal customizations to config.h should probably go in a config.h, not the global AUR package. #4 Thank you for switching to the tag versions rather than date, but you forgot to update SRCINFO!

mar77i commented on 2016-09-03 11:44 (UTC) (edited on 2016-09-03 11:46 (UTC) by mar77i)

great idea prash, I included that.

prash commented on 2016-08-26 10:07 (UTC)

Please replace line 49 with patch -Np1 <"$srcdir/$(basename ${file})" That way, users can include URLs for patches hosted at They might have to modify the sha1sums array, but that's something they can figure out while modifying the source array.

tetris4life commented on 2016-08-07 00:12 (UTC)

I was running into an issue where I built the package which created a config.h and later on I patched the config.def.h but it was not used due to the now existing config.h I just deleted the config.h and the package recreated it taking the now patched version of config.def.h Just something to be aware of if you are applying patches and redoing the makepkg.

JonnyRobbie commented on 2016-05-03 20:08 (UTC)

So where should we put config.h and diff patches? The directory with PKGBUILD doesn't seem to work.

JonnyRobbie commented on 2016-05-03 18:41 (UTC)

fedemp: that's beacause `"${source[@]}"` in PKGBUILD points to git:// instead to your clone directory. If you use $AURDEST you might be able to modify PGKBUILD to use files from there....I haven't figured out how yet...

ubone commented on 2016-04-21 17:25 (UTC)

Just a tip. If you want a brighter red cursor change " 1 " to " 9 " in " -e '/int defaultcs/s/= .*/= 1;/' \ " for other colours

fedemp commented on 2016-03-11 14:31 (UTC)

config.h in the source directory is not used at compilation time. i.e. I created a config.h in the same directory where I have PKGBUILD.

bidulock commented on 2015-09-19 05:18 (UTC)

conflicts with ncurses-6.0-3 in core do not install terminfo entries

phillid commented on 2015-09-03 11:47 (UTC)

Please change instances of $SRCDEST to $srcdir. This PKGBUILD works fine until you have an SRCDEST set in makepkg.conf which isn't the same as the working directory.

vesath commented on 2015-06-16 00:33 (UTC)

Anyone that cares is now free to adopt this package.

karol_007 commented on 2015-06-15 22:29 (UTC)

Maybe you should rename this package to st-scrollback-git or something like this. dwm package is in the repos:

vesath commented on 2015-06-15 06:23 (UTC)

I'm only interested in maintaining a version with the scrollback patch applied; it should also be nonintrusive in the sense that this patch does not change the behavior of st for people that do not press Shift+PgUp. But if you prefer a vanilla package I'd be happy to orphan it. Regarding the config.h issue I'm not sure what you mean; please provide a patch.

phillid commented on 2015-06-15 05:59 (UTC)

Shouldn't this package be vanilla? Surely a separate package with a different name and with the scrollback patch applied would be more appropriate. Please also look into supporting a config.h like the dwm and st packages.

vesath commented on 2015-02-26 05:16 (UTC)

Thanks shoober420; the new version I just commited fixes that.

shoober420 commented on 2015-01-19 20:49 (UTC)

The terminfo for st-256color is missing. I have had to install the st-git-zsh package in the meantime until this is addressed. Anything involving color can't be opened and gets an error saying, "error opening terminal: st-256color". Please look at the comment from this thread.

vesath commented on 2014-11-24 18:46 (UTC)

I see. Thanks for reporting. Should be fixed now.

anoknusa commented on 2014-11-24 01:08 (UTC)

This package installs the terminfo files for st to ~/.terminfo. That's what lgbsneak was getting at. Using sudo or logging in as root causes errors when running ncurses applications (e.g. Vim) in st as a result.

vesath commented on 2014-11-15 20:34 (UTC)

lgbsneak: I fail to understand your point. The ncurses package installs /usr/share/terminfo/s/st-* system-wide. What are you saying is still missing from a st-git standpoint?

lgbsneak commented on 2014-11-15 08:10 (UTC)

removing TERMINFO="..." causes tic to install the st-* terminfo files in $HOME/.terminfo for the user runming makepkg, probably a bad idea to modify things outside the pkg build dir. Further, core/ncurses doesn't seem to install the st-* terminfo files so they are thus not available to users other than the one who built the package. Mostly this causes grief running curses programs as sudo in st.

vesath commented on 2014-11-10 03:08 (UTC)

Thanks for noticing!

karol_007 commented on 2014-11-10 01:14 (UTC)

This package conflicts with testing/ncurses, which adds st to the terminfo database by default. Seems it's enough to remove the TERMINFO="$pkgdir/usr/share/terminfo" part from the PKGBUILD.

karol_007 commented on 2014-10-31 20:26 (UTC)

pkg-config is in base-devel group which is a prerequisite for using AUR, no need to put it in makedepends:

R_Rios commented on 2014-10-31 20:07 (UTC)

pkg-config is missing in makedepends.

rpodgorny commented on 2013-12-02 01:31 (UTC)

ahhh! never mind, my bad! sorry.

rpodgorny commented on 2013-12-02 01:30 (UTC)

this installs the binary to /sbin which violates the /usr move. please fix it, thank you!

vesath commented on 2013-04-10 08:06 (UTC)

Army: Right; I'll push an update in a few minutes.

commented on 2013-04-10 07:40 (UTC)

Hmm, maybe it's just a makedependency?

vesath commented on 2013-04-10 03:17 (UTC)

Army: Not sure why you/namcap thought libxext is not needed anymore; try compiling without it...

vesath commented on 2013-04-10 03:11 (UTC)

Army: Good job! You convinced me. :)

commented on 2013-04-09 09:14 (UTC)

> In my opinion, it should be makepkg's job to define a reasonable pkgver default Well, the thing is, it doesn't. The way your PKGBUILD is written, the pkgver doesn't ever get bumped.

vesath commented on 2013-04-07 19:07 (UTC)

In my opinion, it should be makepkg's job to define a reasonable pkgver default, since it pretends to handle VCS sources transparently; adding a custom function in the PKGBUILD adds complexity for little gain. Also, I believe it will fail on machines which do not have git installed (even if git is in the PKGBUILD's makedepends). Additionally, PKGBUILD should not be written differently whether they are meant for the AUR or proper repositories ([core], [extra], [community]); in fact, some people (including me), maintain repositories of AUR packages. The epoch variable serves a purpose there, and I see no reason why the AUR should care whether it is used or not.

commented on 2013-04-07 18:22 (UTC)

Oh and you should consider adding a pkgver function, so the pkgver is being updated accordingly. On the Wiki there are some suggestions.

commented on 2013-04-07 18:21 (UTC)

No hard feelings, it was just a suggestion, in case you didn't do it already and liked it the way I did or people like bananagranola, who I think might like my PKGBUILD. But one thing: On the mailing list there was/is a discussion wether or not we should use epoch on the AUR and most people agree we shouldn't use epoch, since this was introduced for the repos in case pacman wouldn't recognzie a package upgrade to be an update. I myself am not completely sure on this matter. I won't use epoch, especially not on a git package. I just want to mention this.

vesath commented on 2013-04-07 17:34 (UTC)

Thanks Army. Actually I had made a PKGBUILD for pacman-4.1 myself. However, I am very much against adding patches in particular when that makes the PKGBUILD non-deterministic. Of course, you should feel free to maintain your own PKGBUILD with the patches and configuration you like.

commented on 2013-04-07 16:47 (UTC)

Hi, I made a PKGBUILD for st-git which supports pacman's new features. It supports patches and a custom config.h. According to namcap, libxext is no longer a dependency, so I removed it. Feel free to use it!

bananagranola commented on 2013-02-26 06:36 (UTC)

@vesath, thanks for the reply and the tip.

vesath commented on 2013-02-25 09:21 (UTC)

bananagranola: No, sorry. The $startdir variable was deprecated long ago, and relying on a file that might or might not be there depending on what build tool is used (makepkg, makechrootpkg, etc.) does not make for a clean PKGBUILD. What I recommend you do instead is maintain your own PKGBUILD (with sources and sha1sums entries for your config.h) and merge the changes with this "vanilla" AUR version at every update - that should not happen too often, and the merge should be straightforward.

bananagranola commented on 2013-02-25 06:47 (UTC)

Any chance of using something like this (borrowed from monsterwm-git's PKGBUILD) to allow for a custom config.h?

vesath commented on 2012-11-30 01:41 (UTC)

This package is now superseded by st-git.

commented on 2012-11-29 17:23 (UTC)

suckless moved to git, the hg repo doesn't exist anymore

vesath commented on 2012-07-26 23:13 (UTC)

npouillard: Why? St does not link to libxft...

npouillard commented on 2012-07-26 12:12 (UTC)

libxft seems to be missing as a dep

djpohly commented on 2012-02-09 18:50 (UTC)

@TheBeast: Have you tried running it? Seems to work fine here.

commented on 2012-02-09 18:42 (UTC)

line 32 should read: cd "${srcdir}/st/build" otherwise 'make install' will fail.

vesath commented on 2011-05-21 23:43 (UTC)

This new version should fix your issue.

djpohly commented on 2011-05-21 23:20 (UTC)

That's because the PKGBUILD doesn't quite follow /usr/share/pacman/PKGBUILD-hg.proto. Try the one posted in the comment below to see if it works for you.

commented on 2011-05-21 23:14 (UTC)

I have noticed an issue with trying to compile more than once. I compiled, modified my config.h, and couldn't proceed because the src/st directory wasn't empty. I wish I could fix it and just submit the fix, but I can't seem to figure it out at the moment.

djpohly commented on 2010-10-07 23:36 (UTC)

Here is an updated PKGBUILD that uses incorporates the suggestions below: It uses the new package() function, and it also allows you to substitute your own config.h for the default.

djpohly commented on 2010-07-23 18:50 (UTC)

Thanks for the package! I have a couple suggestions: * The "make install" step uses tic to compile terminfo descriptions, so makedepends should include 'ncurses'. * The terminfo files are currently compiled to the user's ~/.terminfo directory. In order to put these files in the package instead, there need to be two modifications to the PKGBUILD: install -d $startdir/pkg/usr/share/terminfo make PREFIX=/usr DESTDIR=$startdir/pkg TERMINFO=$startdir/pkg/usr/share/terminfo install || return 1 Cheers!