Re: [HACKERS] psql setenv command
On 11/28/2011 09:19 PM, Josh Kupershmidt wrote: Other than those small gripes, the patch looks fine. Attached is an updated version to save you some keystrokes. Thanks. Committed. cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] psql setenv command
On Sat, Nov 26, 2011 at 11:02 AM, Andrew Dunstan wrote:
>> Also, should the malloc() of newval just use pg_malloc() instead?
>
> Yes, also done.
This bit is unnecessary, since pg_malloc() takes care of the error handling:
+ if (!newval)
+ {
+ psql_error("out of memory\n");
+ exit(EXIT_FAILURE);
+ }
Also, the help output for setenv bleeds over an 80-character terminal,
and it seems the rest of the help outputs try to stay under this
limit. And an OCD nitpick: most of the psql-ref.sgml examples show
'testdb' at the prompt, how about we follow along.
Other than those small gripes, the patch looks fine. Attached is an
updated version to save you some keystrokes.
Josh
diff --git a/doc/src/sgml/ref/psql-ref.sgml b/doc/src/sgml/ref/psql-ref.sgml
index 01f57c4..f97929b 100644
*** a/doc/src/sgml/ref/psql-ref.sgml
--- b/doc/src/sgml/ref/psql-ref.sgml
*** lo_import 152801
*** 2242,2247
--- 2242,2265
+ \setenv [ name [ value ] ]
+
+
+
+ Sets the environment variable name to value, or if the
+ value is
+ not supplied, unsets the environment variable. Example:
+
+ testdb=> \setenv PAGER less
+ testdb=> \setenv LESS -imx4F
+
+
+
+
+
+
\sf[+] function_description
diff --git a/src/bin/psql/command.c b/src/bin/psql/command.c
index 9cc73be..e4b4eaa 100644
*** a/src/bin/psql/command.c
--- b/src/bin/psql/command.c
*** exec_command(const char *cmd,
*** 1110,1115
--- 1110,1160
free(opt0);
}
+
+ /* \setenv -- set environment command */
+ else if (strcmp(cmd, "setenv") == 0)
+ {
+ char *envvar = psql_scan_slash_option(scan_state,
+ OT_NORMAL, NULL, false);
+ char *envval = psql_scan_slash_option(scan_state,
+ OT_NORMAL, NULL, false);
+
+ if (!envvar)
+ {
+ psql_error("\\%s: missing required argument\n", cmd);
+ success = false;
+ }
+ else if (strchr(envvar,'=') != NULL)
+ {
+ psql_error("\\%s: environment variable name must not contain '='\n",
+ cmd);
+ success = false;
+ }
+ else if (!envval)
+ {
+ /* No argument - unset the environment variable */
+ unsetenv(envvar);
+ success = true;
+ }
+ else
+ {
+ /* Set variable to the value of the next argument */
+ int len = strlen(envvar) + strlen(envval) + 1;
+ char *newval = pg_malloc(len + 1);
+
+ snprintf(newval, len+1, "%s=%s", envvar, envval);
+ putenv(newval);
+ success = true;
+ /*
+ * Do not free newval here, it will screw up the environment
+ * if you do. See putenv man page for details. That means we
+ * leak a bit of memory here, but not enough to worry about.
+ */
+ }
+ free(envvar);
+ free(envval);
+ }
+
/* \sf -- show a function's source code */
else if (strcmp(cmd, "sf") == 0 || strcmp(cmd, "sf+") == 0)
{
diff --git a/src/bin/psql/help.c b/src/bin/psql/help.c
index 4649e94..13d8bf6 100644
*** a/src/bin/psql/help.c
--- b/src/bin/psql/help.c
*** slashUsage(unsigned short int pager)
*** 158,164
{
FILE *output;
! output = PageOutput(93, pager);
/* if you add/remove a line here, change the row count above */
--- 158,164
{
FILE *output;
! output = PageOutput(94, pager);
/* if you add/remove a line here, change the row count above */
*** slashUsage(unsigned short int pager)
*** 257,262
--- 257,263
fprintf(output, _("Operating System\n"));
fprintf(output, _(" \\cd [DIR] change the current working directory\n"));
+ fprintf(output, _(" \\setenv NAME [VALUE] set or unset environment variable\n"));
fprintf(output, _(" \\timing [on|off] toggle timing of commands (currently %s)\n"),
ON(pset.timing));
fprintf(output, _(" \\! [COMMAND] execute command in shell or start interactive shell\n"));
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] psql setenv command
On 11/20/2011 11:07 AM, Josh Kupershmidt wrote:
On Wed, Nov 2, 2011 at 5:36 PM, Andrew Dunstan wrote:
Updated patch is attached - adding to Nov commitfest.
Review of the v2 patch:
* Submission Review
Patch applies with some fuzz and builds without warnings. I noticed
some tab characters being used in psql-ref.sgml where they shouldn't
be.
Fixed.
* Coding Review / Nitpicks
The patch implements \setenv via calls to unsetenv() and putenv(). As
the comment notes,
| That means we
| leak a bit of memory here, but not enough to worry about.
which seems true; the man page basically says there's nothing to be
done about the situation.
The calls to putenv() and unsetenv() are done without any real input
checking. So this admittedly-pathological case produces surprising
results:
test=# \setenv foo=bar baz
test=# \! echo $foo
bar=baz
Perhaps 'envvar' arguments with a '=' in the argument should just be
disallowed.
Done that way.
Also, should the malloc() of newval just use pg_malloc() instead?
Yes, also done.
Revised patch attached.
cheers
andrew
diff --git a/doc/src/sgml/ref/psql-ref.sgml b/doc/src/sgml/ref/psql-ref.sgml
index 01f57c4..39193d5 100644
--- a/doc/src/sgml/ref/psql-ref.sgml
+++ b/doc/src/sgml/ref/psql-ref.sgml
@@ -2242,6 +2242,24 @@ lo_import 152801
+\setenv [ name [ value ] ]
+
+
+
+Sets the environment variable name to value, or if the
+value is
+not supplied, unsets the environment variable. Example:
+
+foo=> \setenv PAGER less
+foo=> \setenv LESS -imx4F
+
+
+
+
+
+
\sf[+] function_description
diff --git a/src/bin/psql/command.c b/src/bin/psql/command.c
index 9cc73be..b5331aa 100644
--- a/src/bin/psql/command.c
+++ b/src/bin/psql/command.c
@@ -1110,6 +1110,56 @@ exec_command(const char *cmd,
free(opt0);
}
+
+ /* \setenv -- set environment command */
+ else if (strcmp(cmd, "setenv") == 0)
+ {
+ char *envvar = psql_scan_slash_option(scan_state,
+ OT_NORMAL, NULL, false);
+ char *envval = psql_scan_slash_option(scan_state,
+ OT_NORMAL, NULL, false);
+
+ if (!envvar)
+ {
+ psql_error("\\%s: missing required argument\n", cmd);
+ success = false;
+ }
+ else if (strchr(envvar,'=') != NULL)
+ {
+ psql_error("\\%s: environment variable name must not contain '='\n",
+ cmd);
+ success = false;
+ }
+ else if (!envval)
+ {
+ /* No argument - unset the environment variable */
+ unsetenv(envvar);
+ success = true;
+ }
+ else
+ {
+ /* Set variable to the value of the next argument */
+ int len = strlen(envvar) + strlen(envval) + 1;
+ char *newval = pg_malloc(len + 1);
+
+ if (!newval)
+ {
+psql_error("out of memory\n");
+exit(EXIT_FAILURE);
+ }
+ snprintf(newval, len+1, "%s=%s", envvar, envval);
+ putenv(newval);
+ success = true;
+ /*
+ * Do not free newval here, it will screw up the environment
+ * if you do. See putenv man page for details. That means we
+ * leak a bit of memory here, but not enough to worry about.
+ */
+ }
+ free(envvar);
+ free(envval);
+ }
+
/* \sf -- show a function's source code */
else if (strcmp(cmd, "sf") == 0 || strcmp(cmd, "sf+") == 0)
{
diff --git a/src/bin/psql/help.c b/src/bin/psql/help.c
index 4649e94..20fb5d7 100644
--- a/src/bin/psql/help.c
+++ b/src/bin/psql/help.c
@@ -158,7 +158,7 @@ slashUsage(unsigned short int pager)
{
FILE *output;
- output = PageOutput(93, pager);
+ output = PageOutput(94, pager);
/* if you add/remove a line here, change the row count above */
@@ -257,6 +257,7 @@ slashUsage(unsigned short int pager)
fprintf(output, _("Operating System\n"));
fprintf(output, _(" \\cd [DIR] change the current working directory\n"));
+ fprintf(output, _(" \\setenv NAME [VALUE] set environment variable, or unset it if no value provided\n"));
fprintf(output, _(" \\timing [on|off] toggle timing of commands (currently %s)\n"),
ON(pset.timing));
fprintf(output, _(" \\! [COMMAND] execute command in shell or start interactive shell\n"));
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] psql setenv command
On Wed, Nov 2, 2011 at 5:36 PM, Andrew Dunstan wrote: > Updated patch is attached - adding to Nov commitfest. Review of the v2 patch: * Submission Review Patch applies with some fuzz and builds without warnings. I noticed some tab characters being used in psql-ref.sgml where they shouldn't be. * Usability Review I sort of doubt I'll use the feature myself, but there was at least one +1 for the feature idea already, so it seems useful enough. That said, the stated motivation for the patch: > First, it would be useful to be able to set pager options and possibly other > settings, so my suggestion is for a \setenv command that could be put in a > .psqlrc file, something like: seems like it would be more suited to being set in the user's ~/.profile (perhaps via an 'alias' if you didn't want the changes to apply globally). So unless I miss something, the real niche for the patch seems to be for people to interactively change environment settings while within psql. Again, not something I'm keen on for my own use, but if others think it's useful, that's good enough for me. * Coding Review / Nitpicks The patch implements \setenv via calls to unsetenv() and putenv(). As the comment notes, | That means we | leak a bit of memory here, but not enough to worry about. which seems true; the man page basically says there's nothing to be done about the situation. The calls to putenv() and unsetenv() are done without any real input checking. So this admittedly-pathological case produces surprising results: test=# \setenv foo=bar baz test=# \! echo $foo bar=baz Perhaps 'envvar' arguments with a '=' in the argument should just be disallowed. Also, should the malloc() of newval just use pg_malloc() instead? * Reviewer Review I haven't tested on Windows. Josh -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] psql setenv command
On 09/26/2011 05:16 PM, Andrew Dunstan wrote:
On 09/26/2011 05:07 PM, Jeff Janes wrote:
But in any case, considering that we are both wondering if it works on
Windows, I think that argues that an automatic regression test would
be very handy.
I think an automated test should be possible. Something like:
\setenv PGFOO blurfl
\! echo $PGFOO %PGFOO%
and then have a couple of alternative results. When I get time to get
back to this I'll experiment.
I can confirm it does work on Windows:
C:\prog\bf\root\HEAD\testinst>type ..\..\..\setenv.sql
\setenv PGFOO foo
\! echo $PGFOO %PGFOO%
\setenv PGFOO
\! echo $PGFOO %PGFOO%
C:\prog\bf\root\HEAD\testinst>bin\psql -f ..\..\..\setenv.sql postgres
$PGFOO foo
$PGFOO %PGFOO%
I think I agree on reflection with Josh Kupershmidt that we don't need a
regression test for this.
Updated patch is attached - adding to Nov commitfest.
cheers
andrew
diff --git a/doc/src/sgml/ref/psql-ref.sgml b/doc/src/sgml/ref/psql-ref.sgml
index d6941e0..d8ed5c8 100644
--- a/doc/src/sgml/ref/psql-ref.sgml
+++ b/doc/src/sgml/ref/psql-ref.sgml
@@ -2237,6 +2237,24 @@ lo_import 152801
+\setenv [ name [ value ] ]
+
+
+
+Sets the environment variable name to value, or if the
+ value is
+ not supplied, unsets the environment variable. Example:
+
+foo=> \setenv PAGER less
+foo=> \setenv LESS -imx4F
+
+
+
+
+
+
\sf[+] function_description
diff --git a/src/bin/psql/command.c b/src/bin/psql/command.c
index 2c38902..7a91905 100644
--- a/src/bin/psql/command.c
+++ b/src/bin/psql/command.c
@@ -1104,6 +1104,50 @@ exec_command(const char *cmd,
free(opt0);
}
+
+ /* \setenv -- set environment command */
+ else if (strcmp(cmd, "setenv") == 0)
+ {
+ char *envvar = psql_scan_slash_option(scan_state,
+ OT_NORMAL, NULL, false);
+ char *envval = psql_scan_slash_option(scan_state,
+ OT_NORMAL, NULL, false);
+
+ if (!envvar)
+ {
+ psql_error("\\%s: missing required argument\n", cmd);
+ success = false;
+ }
+ else if (!envval)
+ {
+ /* No argument - unset the environment variable */
+ unsetenv(envvar);
+ success = true;
+ }
+ else
+ {
+ /* Set variable to the value of the next argument */
+ int len = strlen(envvar) + strlen(envval) + 1;
+ char *newval = malloc(len + 1);
+
+ if (!newval)
+ {
+psql_error("out of memory\n");
+exit(EXIT_FAILURE);
+ }
+ snprintf(newval, len+1, "%s=%s", envvar, envval);
+ putenv(newval);
+ success = true;
+ /*
+ * Do not free newval here, it will screw up the environment
+ * if you do. See putenv man page for details. That means we
+ * leak a bit of memory here, but not enough to worry about.
+ */
+ }
+ free(envvar);
+ free(envval);
+ }
+
/* \sf -- show a function's source code */
else if (strcmp(cmd, "sf") == 0 || strcmp(cmd, "sf+") == 0)
{
diff --git a/src/bin/psql/help.c b/src/bin/psql/help.c
index 53e4cd0..5c2172e 100644
--- a/src/bin/psql/help.c
+++ b/src/bin/psql/help.c
@@ -158,7 +158,7 @@ slashUsage(unsigned short int pager)
{
FILE *output;
- output = PageOutput(93, pager);
+ output = PageOutput(94, pager);
/* if you add/remove a line here, change the row count above */
@@ -257,6 +257,7 @@ slashUsage(unsigned short int pager)
fprintf(output, _("Operating System\n"));
fprintf(output, _(" \\cd [DIR] change the current working directory\n"));
+ fprintf(output, _(" \\setenv NAME [VALUE] set environment variable, or unset it if no value provided\n"));
fprintf(output, _(" \\timing [on|off] toggle timing of commands (currently %s)\n"),
ON(pset.timing));
fprintf(output, _(" \\! [COMMAND] execute command in shell or start interactive shell\n"));
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] psql setenv command
On 09/26/2011 05:07 PM, Jeff Janes wrote: But in any case, considering that we are both wondering if it works on Windows, I think that argues that an automatic regression test would be very handy. I think an automated test should be possible. Something like: \setenv PGFOO blurfl \! echo $PGFOO %PGFOO% and then have a couple of alternative results. When I get time to get back to this I'll experiment. cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] psql setenv command
On Mon, Sep 26, 2011 at 12:07 PM, Josh Kupershmidt wrote: > On Thu, Sep 15, 2011 at 7:02 PM, Andrew Dunstan wrote: >> On Thu, September 15, 2011 6:10 pm, Josh Kupershmidt wrote: >>> [need way to show current values] >> \! echo $foo >> >> (which is how I tested the patch, of course) > > Ah, right. IMO it'd be helpful to mention that echo example in your > changes to psql-ref.sgml, either as part of your example inside the > , or as a suggestion with the rest of the text. > > BTW, have you tested this on Windows? I don't have a Windows machine > handy to fool with, but I do see what might be a mess/confusion on > that platform. The MSDN docs claim[1] that putenv() is deprecated in > favor of _putenv(). The code in pg_upgrade uses > SetEnvironmentVariableA on WIN32, while win32env.c has a wrapper > function pgwin32_putenv() around _putenv(). I also wondered this and also don't have a Windows build system. The win32.h uses a macro to turn putenv() into pgwin32_putenv() , so as long as that macro is in effect I think it should be doing the right thing. In any event, there are several other places in the existing code-base that call putenv() in a similar fashion to the new code, so it if doesn't work I would expect things to already be falling over. > > On Sat, Sep 24, 2011 at 5:18 PM, Jeff Janes wrote: >> A description of the \setenv command should show up in the output of \?. > > Yeah, Andrew agreed upthread that help.c should be amended as well, > which would fix \?. Yes, sorry for the accidental nag. I didn't realize that help.c is what implements \? until after I posted. > >> Should there be a regression test for this? I'm not sure how it would >> work, as I don't see a cross-platform way to see what the variable is >> set to. > > Similar recent psql changes haven't had regression tests included, and > I don't see much of a need here either. I wasn't sure of the convention on that. I intentionally broke a few \ commands (because that was easier than reading through all of regress) and it did start failing, but that looks like that is because those commands are used incidentally as part of other tests, rather than having tests in their own right. But in any case, considering that we are both wondering if it works on Windows, I think that argues that an automatic regression test would be very handy. Cheers, Jeff -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] psql setenv command
On Thu, Sep 15, 2011 at 7:02 PM, Andrew Dunstan wrote: > On Thu, September 15, 2011 6:10 pm, Josh Kupershmidt wrote: >> [need way to show current values] > \! echo $foo > > (which is how I tested the patch, of course) Ah, right. IMO it'd be helpful to mention that echo example in your changes to psql-ref.sgml, either as part of your example inside the , or as a suggestion with the rest of the text. BTW, have you tested this on Windows? I don't have a Windows machine handy to fool with, but I do see what might be a mess/confusion on that platform. The MSDN docs claim[1] that putenv() is deprecated in favor of _putenv(). The code in pg_upgrade uses SetEnvironmentVariableA on WIN32, while win32env.c has a wrapper function pgwin32_putenv() around _putenv(). On Sat, Sep 24, 2011 at 5:18 PM, Jeff Janes wrote: > A description of the \setenv command should show up in the output of \?. Yeah, Andrew agreed upthread that help.c should be amended as well, which would fix \?. > Should there be a regression test for this? I'm not sure how it would > work, as I don't see a cross-platform way to see what the variable is > set to. Similar recent psql changes haven't had regression tests included, and I don't see much of a need here either. -- [1] http://msdn.microsoft.com/en-US/library/ms235321%28v=VS.80%29.aspx Josh -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] psql setenv command
On Thu, Sep 15, 2011 at 7:46 AM, Andrew Dunstan wrote: > On Thu, September 15, 2011 10:44 am, Andrew Dunstan wrote: >> >> As discussed, patch attached. >> > > > this time with patch. Hi Andrew, A description of the \setenv command should show up in the output of \?. Should there be a regression test for this? I'm not sure how it would work, as I don't see a cross-platform way to see what the variable is set to. Thanks, Jeff -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] psql setenv command
On Thu, September 15, 2011 6:10 pm, Josh Kupershmidt wrote: > On Thu, Sep 15, 2011 at 10:46 AM, Andrew Dunstan > wrote: >> this time with patch. > > I think help.c should document the \setenv command. And a link from > the "Environment" section[1] of psql's doc page to the section about > \setenv might help too. Good point. > > The existing \set command lists all internal variables and their > values when called with no arguments. Perhaps \setenv with no > arguments should work similarly: we could display only those > environment variables interesting to psql if there's too much noise. > Or at least, I think we need some way to check the values of > environment variables inside psql, if we're able to set them from > inside psql. To be fair, I notice that \pset doesn't appear to offer a > way to show its current values either, but maybe that should be fixed > separately as well. \! echo $foo (which is how I tested the patch, of course) > > Typo: s/vakue/value/ > Yeah, I noticed that after, thanks. cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] psql setenv command
On Thu, Sep 15, 2011 at 10:46 AM, Andrew Dunstan wrote: > this time with patch. I think help.c should document the \setenv command. And a link from the "Environment" section[1] of psql's doc page to the section about \setenv might help too. The existing \set command lists all internal variables and their values when called with no arguments. Perhaps \setenv with no arguments should work similarly: we could display only those environment variables interesting to psql if there's too much noise. Or at least, I think we need some way to check the values of environment variables inside psql, if we're able to set them from inside psql. To be fair, I notice that \pset doesn't appear to offer a way to show its current values either, but maybe that should be fixed separately as well. Typo: s/vakue/value/ Josh -- [1] http://www.postgresql.org/docs/current/static/app-psql.html#APP-PSQL-ENVIRONMENT -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] psql setenv command
On Thu, September 15, 2011 10:44 am, Andrew Dunstan wrote: > > As discussed, patch attached. > this time with patch. setenv.patch Description: Binary data -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] psql setenv command
As discussed, patch attached. cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
