Sometimes UNIX “just works”:
ls | cut -f 1 -d . | paste -s -d ” ” –
Sometimes UNIX “just works”:
ls | cut -f 1 -d . | paste -s -d ” ” –
So here’s a little story about eBay, inspired by my recent attempts to buy a used laptop, from a (likely, highly unreputable) seller. I will name names.
I spent a good part of Sunday this week trolling eBay, searching for the best deal on a used laptop for some upcoming programming projects I have in mind. After researching and researching, digging up Thinkpad Personal Systems Reference books, and all sorts of other Manufacturer parts specs, I bid on a Dell from a user named “terbusinesses“.
The bid was on item 200884952022, which was initially a Buy It Now auction with a $350 starting bid and a $400 Buy It Now option. So, at 12:26pm Central Time, I bid $350. And I received a confirmation notice from eBay that I was the High Bidder. It looked like this:
For those in the know, once a bid has been placed on a Buy It Now auction, the actual option to Buy It Now goes away, the auction becomes a normal highest-bidder-wins type of auction.
A few hours later, I’m browsing eBay, and notice that “terbusinesses” has listed the identical item that I’m bidding on under a second auction, item 200886900878, which is the same sort of Buy It Now auction with a $350 starting bid with a $400 Buy It Now option. I don’t have a screenshot of this, but I know what I saw.
A few hours later, I get an e-mail: “eBay Bid Cancellation Notice – Item 200884952022 : DELL LATITUDE E6420 LAPTOP MOUSE, 4GB, CORE i5 WIN 7 INTEL HD 2.5 GHZ 320 GB HDD”. It looks like this:
That’s interesting, I think.
So somehow, this seller/scammer is hooking people into Buy It Now deals, and cancelling previous in-progress auctions. I’m not sure how this works on eBay’s side, because I don’t believe it should be possible to prematurely end a normal in-progress auction. And it certainly shouldn’t be legit to list the same item twice, then accept only the auction result that you want. In any case, this certainly doesn’t do much to build my confidence that the platform is fair, if this is a widespread thing.
The stupid bullshit reason that eBay gives when I look at the original item I bid on is: “This listing was ended by the seller because the item is no longer available.”, which is crazy. Tell me that at 12pm today there were “2” of the same item being sold by someone, and now there are none?
Playing with my Mac this evening, the following system popup appeared, while I’m browsing around the web:
I’m always a bit suspicious, esp. if it shows up when I’m wandering around the web in Chrome. I assume nothing can get out of the sandbox, but who knows? I’ve already disabled the Java plugin, and nondescript programs asking me to type in my admin password always make me pause.
Various Google searches return non-helpful results, since it splits “finish” and “installation”, and, again doesn’t do order-dependent or phrase searches. And since most of the phrase is pretty non-unique, the results aren’t great.
But, I did manage to find this post on MacRumors.
Turns out the “finish_installation” is part of Sparkle, which is that handy-dandy autoupdate framework. But it’s not helpful when you don’t know which app is requesting the update, and/or if this app is legit.
So open up Activity Monitor, and Inspect the finish_installation process, which will tell you what you want to know.
In this case, the app to be updated is the Amazon Cloud Drive program, which is legit.
Let’s say you have a little accident while messing with the schema of your PostGIS-enabled database, and the spatial_ref_sys and geometry_columns tables get wiped out. When you go to install a GeoDjango-enabled app such as the example “world” app, Python will yell at you, and you will be very sad:
1
2
3
4
5
6
7
8
|
$ python manage.py syncdb
Failed to install index for world.WorldBorder model: relation "spatial_ref_sys" does not exist
LINE 1: SELECT SRID FROM spatial_ref_sys WHERE SRID = new_sr...
^
QUERY: SELECT SRID FROM spatial_ref_sys WHERE SRID = new_srid
CONTEXT: PL/pgSQL function "addgeometrycolumn" line 75 at SQL statement
SQL statement "SELECT AddGeometryColumn('','',$1,$2,$3,$4,$5)"
PL/pgSQL function "addgeometrycolumn" line 5 at SQL statement
|
It fails, because you accidentally dropped some very important PostGIS tables from the database. So you google a bit and find this: http://postgis.refractions.net/documentation/manual-1.5/ch02.html#id418654 which tells you what you need to do to set up a clean PostGIS installation.
So you dig around in the shared host, until you find where the PostGIS files are, and in particular spatial_ref_sys.sql:
1
2
3
4
5
6
7
|
$ find . -name *.sql
./share/contrib/postgis-1.5/postgis_upgrade_14_to_15.sql
./share/contrib/postgis-1.5/postgis_upgrade_13_to_15.sql
./share/contrib/postgis-1.5/postgis_upgrade_15_minor.sql
./share/contrib/postgis-1.5/spatial_ref_sys.sql
./share/contrib/postgis-1.5/uninstall_postgis.sql
./share/contrib/postgis-1.5/postgis.sql
|
So you try to run spatial_ref_sys.sql, and it fails, and you are sad:
1
2
3
4
5
6
7
|
$ psql -h localhost -U user -d database -f spatial_ref_sys.sql
[...]
psql:spatial_ref_sys.sql:5: ERROR: relation "spatial_ref_sys" does not exist
LINE 1: INSERT INTO "spatial_ref_sys" ("srid","auth_name","auth_srid...
^
psql:spatial_ref_sys.sql:9: ERROR: current transaction is aborted, commands ignored until end of transaction block
[...]
|
Normally to create the missing table, you would run the postgis.sql script, and it would create these tables alongside the various GIS stored procedures. On a shared host, this probably won’t be possible, because you won’t have the permissions:
1
2
3
4
5
|
$ psql -h localhost -U user -d database -f postgis.sql
[...]
psql:postgis.sql:59: ERROR: permission denied for language c
psql:postgis.sql:65: ERROR: current transaction is aborted, commands ignored until end of transaction block
[...]
|
If you dig through postgis.sql for the proper CREATE TABLE statements, you’ll see something like:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
|
-------------------------------------------------------------------
-- SPATIAL_REF_SYS
-------------------------------------------------------------------
CREATE TABLE spatial_ref_sys (
srid integer not null primary key,
auth_name varchar(256),
auth_srid integer,
srtext varchar(2048),
proj4text varchar(2048)
);
-------------------------------------------------------------------
-- GEOMETRY_COLUMNS
-------------------------------------------------------------------
CREATE TABLE geometry_columns (
f_table_catalog varchar(256) not null,
f_table_schema varchar(256) not null,
f_table_name varchar(256) not null,
f_geometry_column varchar(256) not null,
coord_dimension integer not null,
srid integer not null,
type varchar(30) not null,
CONSTRAINT geometry_columns_pk primary key (
f_table_catalog,
f_table_schema,
f_table_name,
f_geometry_column )
) WITH OIDS;
|
You can pop these into a PostgreSQL admin shell and recreate these tables. Then you just have to rerun the spatial_ref_sys.sql file, and you should see:
1
2
3
4
5
6
7
8
|
$ psql -h localhost -U user -d database -f spatial_ref_sys.sql
BEGIN
INSERT 0 1
INSERT 0 1
INSERT 0 1
INSERT 0 1
INSERT 0 1
INSERT 0 1
|
Then, when you run the Django management script again, it should succeed.