nhyatt/putty-source
1
0
Fork 0
mirror of https://git.tartarus.org/simon/putty.git synced 2025-01-09 17:38:00 +00:00
Code Issues Projects Releases Wiki Activity
cd97b7e7ea
putty-source/psftp.c

2883 lines
84 KiB
C
Raw Normal View History

First stab at an SFTP client. Currently a Unixland testing app, not integrated into PuTTY. [originally from svn r938]
2001-02-23 18:21:44 +00:00
/*
Various tweaks to header comments to remind me which bits are meant to be platform-independent, etc. [originally from svn r4148]
2004-04-27 12:31:57 +00:00
* psftp.c: (platform-independent) front end for PSFTP.
First stab at an SFTP client. Currently a Unixland testing app, not integrated into PuTTY. [originally from svn r938]
2001-02-23 18:21:44 +00:00
*/
#include <stdio.h>
#include <stdlib.h>
SFTP client now successfully handles cd, ls, get and put. [originally from svn r939]
2001-02-24 12:02:35 +00:00
#include <stdarg.h>
First stab at an SFTP client. Currently a Unixland testing app, not integrated into PuTTY. [originally from svn r938]
2001-02-23 18:21:44 +00:00
#include <assert.h>
More upgrades to psftp: it now supports mv, chmod, reget and reput. [originally from svn r1203]
2001-08-26 11:35:11 +00:00
#include <limits.h>
First stab at an SFTP client. Currently a Unixland testing app, not integrated into PuTTY. [originally from svn r938]
2001-02-23 18:21:44 +00:00
psftp now works as part of the PuTTY suite [originally from svn r940]
2001-02-24 16:08:56 +00:00
#include "putty.h"
Next phase of general SFTP reworking: psftp.c is now a platform- independent source file. All Windowsisms have been moved out to winsftp.c. [originally from svn r3418]
2003-08-24 12:47:46 +00:00
#include "psftp.h"
psftp now works as part of the PuTTY suite [originally from svn r940]
2001-02-24 16:08:56 +00:00
#include "storage.h"
#include "ssh.h"
First stab at an SFTP client. Currently a Unixland testing app, not integrated into PuTTY. [originally from svn r938]
2001-02-23 18:21:44 +00:00
#include "sftp.h"
When giving authorisation errors from the proxy code in x11fwd.c, name the proxy using the global 'appname' variable, instead of statically calling it PuTTY. (Knock-on effect is that PSCP and PSFTP have to declare that variable, though of course they shouldn't ever actually _use_ the X forwarding code. Probably I ought to replace it with a stub nox11fwd.c for those applications.) [originally from svn r8501]
2009-04-23 17:39:36 +00:00
const char *const appname = "PSFTP";
Extensive changes that _should_ fix the socket buffering problems, by ceasing to listen on input channels if the corresponding output channel isn't accepting data. Has had basic check-I-didn't-actually- break-anything-too-badly testing, but hasn't been genuinely tested in stress conditions (because concocting stress conditions is non- trivial). [originally from svn r1198]
2001-08-25 17:09:23 +00:00
/*
* Since SFTP is a request-response oriented protocol, it requires
* no buffer management: when we send data, we stop and wait for an
* acknowledgement _anyway_, and so we can't possibly overfill our
* send buffer.
*/
Allow PSFTP to be run with no arguments, in which case it enters the command-line state but all commands are disallowed except `open host.name'. The idea is to provide marginal extra niceness for people who double-click the icon without realising it's a cmdline app. [originally from svn r1480]
2001-12-13 18:42:34 +00:00
static int psftp_connect(char *userhost, char *user, int portnumber);
Oops - get the forward declaration right in that hack [originally from svn r1566]
2002-02-27 22:30:57 +00:00
static int do_sftp_init(void);
Add missing 'static' on file-internal declarations. sk_startup and sk_nextaddr are entirely internal to winnet.c; nearly all of import.c and minibidi.c's internal routines should have been static and weren't; {read,write}_utf8 are internal to charset/utf8.c (and didn't even need separate declarations at all); do_sftp_cleanup is internal to psftp.c, and get_listitemheight to gtkdlg.c. While I was editing those prototypes anyway, I've also added missing 'const' to the 'char *' passphrase parameters in import,c.
2018-11-03 08:25:28 +00:00
static void do_sftp_cleanup(void);
Allow PSFTP to be run with no arguments, in which case it enters the command-line state but all commands are disallowed except `open host.name'. The idea is to provide marginal extra niceness for people who double-click the icon without realising it's a cmdline app. [originally from svn r1480]
2001-12-13 18:42:34 +00:00
First stab at an SFTP client. Currently a Unixland testing app, not integrated into PuTTY. [originally from svn r938]
2001-02-23 18:21:44 +00:00
/* ----------------------------------------------------------------------
* sftp client state.
*/
Make more file-scope variables static. In the previous trawl of this, I didn't bother with the statics in main-program modules, on the grounds that my main aim was to avoid 'library' objects (shared between multiple programs) from polluting the global namespace. But I think it's worth being more strict after all, so this commit adds 'static' to a lot more file-scope variables that aren't needed outside their own module.
2020-02-02 10:00:43 +00:00
static char *pwd, *homedir;
Fix assorted memory leaks. Affects command-line PuTTYgen, PSFTP, and anything running the SSH-2 userauth client layer. Tweaked version of a patch due to Tim Kosse.
2019-07-06 16:44:15 +00:00
static LogContext *psftp_logctx = NULL;
Turn Backend into a sensible classoid. Nearly every part of the code that ever handles a full backend structure has historically done it using a pair of pointer variables, one pointing at a constant struct full of function pointers, and the other pointing to a 'void *' state object that's passed to each of those. While I'm modernising the rest of the code, this seems like a good time to turn that into the same more or less type-safe and less cumbersome system as I'm using for other parts of the code, such as Socket, Plug, BinaryPacketProtocol and so forth: the Backend structure contains a vtable pointer, and a system of macro wrappers handles dispatching through that vtable.
2018-09-11 15:23:38 +00:00
static Backend *backend;
Stop having a global Conf. It's now a static in the main source file of each application that uses it, and isn't accessible from any other source file unless the main one passes it by reference. In fact, there were almost no instances of the latter: only the config-box functions in windlg.c were using 'conf' by virtue of its globalness, and it's easy to make those take it as a parameter.
2020-02-02 10:00:42 +00:00
static Conf *conf;
Make more file-scope variables static. In the previous trawl of this, I didn't bother with the statics in main-program modules, on the grounds that my main aim was to avoid 'library' objects (shared between multiple programs) from polluting the global namespace. But I think it's worth being more strict after all, so this commit adds 'static' to a lot more file-scope variables that aren't needed outside their own module.
2020-02-02 10:00:43 +00:00
static bool sent_eof = false;
First stab at an SFTP client. Currently a Unixland testing app, not integrated into PuTTY. [originally from svn r938]
2001-02-23 18:21:44 +00:00
New abstraction 'Seat', to pass to backends. This is a new vtable-based abstraction which is passed to a backend in place of Frontend, and it implements only the subset of the Frontend functions needed by a backend. (Many other Frontend functions still exist, notably the wide range of things called by terminal.c providing platform-independent operations on the GUI terminal window.) The purpose of making it a vtable is that this opens up the possibility of creating a backend as an internal implementation detail of some other activity, by providing just that one backend with a custom Seat that implements the methods differently. For example, this refactoring should make it feasible to directly implement an SSH proxy type, aka the 'jump host' feature supported by OpenSSH, aka 'open a secondary SSH session in MAINCHAN_DIRECT_TCP mode, and then expose the main channel of that as the Socket for the primary connection'. (Which of course you can already do by spawning 'plink -nc' as a separate proxy process, but this would permit it in the _same_ process without anything getting confused.) I've centralised a full set of stub methods in misc.c for the new abstraction, which allows me to get rid of several annoying stubs in the previous code. Also, while I'm here, I've moved a lot of duplicated modalfatalbox() type functions from application main program files into wincons.c / uxcons.c, which I think saves duplication overall. (A minor visible effect is that the prefixes on those console-based fatal error messages will now be more consistent between applications.)
2018-10-11 18:58:42 +00:00
/* ------------------------------------------------------------
* Seat vtable.
*/
Make lots of 'int' length fields into size_t. This is a general cleanup which has been overdue for some time: lots of length fields are now the machine word type rather than the (in practice) fixed 'int'.
2019-02-06 20:42:44 +00:00
static size_t psftp_output(Seat *, bool is_stderr, const void *, size_t);
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
static bool psftp_eof(Seat *);
New abstraction 'Seat', to pass to backends. This is a new vtable-based abstraction which is passed to a backend in place of Frontend, and it implements only the subset of the Frontend functions needed by a backend. (Many other Frontend functions still exist, notably the wide range of things called by terminal.c providing platform-independent operations on the GUI terminal window.) The purpose of making it a vtable is that this opens up the possibility of creating a backend as an internal implementation detail of some other activity, by providing just that one backend with a custom Seat that implements the methods differently. For example, this refactoring should make it feasible to directly implement an SSH proxy type, aka the 'jump host' feature supported by OpenSSH, aka 'open a secondary SSH session in MAINCHAN_DIRECT_TCP mode, and then expose the main channel of that as the Socket for the primary connection'. (Which of course you can already do by spawning 'plink -nc' as a separate proxy process, but this would permit it in the _same_ process without anything getting confused.) I've centralised a full set of stub methods in misc.c for the new abstraction, which allows me to get rid of several annoying stubs in the previous code. Also, while I'm here, I've moved a lot of duplicated modalfatalbox() type functions from application main program files into wincons.c / uxcons.c, which I think saves duplication overall. (A minor visible effect is that the prefixes on those console-based fatal error messages will now be more consistent between applications.)
2018-10-11 18:58:42 +00:00
static const SeatVtable psftp_seat_vt = {
psftp_output,
psftp_eof,
filexfer_get_userpass_input,
nullseat_notify_remote_exit,
console_connection_fatal,
nullseat_update_specials_menu,
nullseat_get_ttymode,
nullseat_set_busy_status,
console_verify_ssh_host_key,
console_confirm_weak_crypto_primitive,
console_confirm_weak_cached_hostkey,
nullseat_is_never_utf8,
nullseat_echoedit_update,
nullseat_get_x_display,
nullseat_get_windowid,
Change Seat's get_char_cell_size to get_window_pixel_size. That's more directly useful in uxpty.c (which is currently the only actual client of the function), and also matches the data that SSH clients send in "pty-req". Also, it makes that method behave more like the GUI query function get_window_pixels used by terminal.c (with the sole exception that unlike g_w_p it's allowed to return failure), so it becomes even more trivial to implement in the GUI front ends.
2018-10-13 06:37:24 +00:00
nullseat_get_window_pixel_size,
Add a Seat vtable method to get a stripctrl. If centralised code like the SSH implementation wants to sanitise escape sequences out of a piece of server-provided text, it will need to do it by making a locale-based StripCtrlChars if it's running in a console context, or a Terminal-based one if it's in a GUI terminal- window application. All the other changes of behaviour needed between those two contexts are handled by providing reconfigurable methods in the Seat vtable; this one is no different. So now there's a new method in the Seat vtable that will construct a StripCtrlChars appropriate to that kind of seat. Terminal-window seats (gtkwin.c, window.c) implement it by calling the new stripctrl_new_term(), and console ones use the locale- based stripctrl_new().
2019-03-05 21:13:00 +00:00
console_stripctrl_new,
Seat method to set the current trust status. In terminal-based GUI applications, this is passed through to term_set_trust_status, to toggle whether lines are prefixed with the new trust sigil. In console applications, the function returns false, indicating to the backend that it should employ some other technique for spoofing protection.
2019-03-10 14:42:11 +00:00
nullseat_set_trust_status_vacuously,
Remove FLAG_VERBOSE. The global 'int flags' has always been an ugly feature of this code base, and I suddenly thought that perhaps it's time to start throwing it out, one flag at a time, until it's totally unused. My first target is FLAG_VERBOSE. This was usually set by cmdline.c when it saw a -v option on the program's command line, except that GUI PuTTY itself sets it unconditionally on startup. And then various bits of the code would check it in order to decide whether to print a given message. In the current system of front-end abstraction traits, there's no _one_ place that I can move it to. But there are two: every place that checked FLAG_VERBOSE has access to either a Seat or a LogPolicy. So now each of those traits has a query method for 'do I want verbose messages?'. A good effect of this is that subsidiary Seats, like the ones used in Uppity for the main SSH server module itself and the server end of shell channels, now get to have their own verbosity setting instead of inheriting the one global one. In fact I don't expect any code using those Seats to be generating any messages at all, but if that changes later, we'll have a way to control it. (Who knows, perhaps logging in Uppity might become a thing.) As part of this cleanup, I've added a new flag to cmdline_tooltype, called TOOLTYPE_NO_VERBOSE_OPTION. The unconditionally-verbose tools now set that, and it has the effect of making cmdline.c disallow -v completely. So where 'putty -v' would previously have been silently ignored ("I was already verbose"), it's now an error, reminding you that that option doesn't actually do anything. Finally, the 'default_logpolicy' provided by uxcons.c and wincons.c (with identical definitions) has had to move into a new file of its own, because now it has to ask cmdline.c for the verbosity setting as well as asking console.c for the rest of its methods. So there's a new file clicons.c which can only be included by programs that link against both cmdline.c _and_ one of the *cons.c, and I've renamed the logpolicy to reflect that.
2020-01-30 06:40:21 +00:00
cmdline_seat_verbose,
Remove FLAG_INTERACTIVE. This is simpler than FLAG_VERBOSE: everywhere we need to check it, we have a Seat available, so we can just make it a Seat query method.
2020-01-30 06:40:21 +00:00
nullseat_interactive_yes,
New abstraction 'Seat', to pass to backends. This is a new vtable-based abstraction which is passed to a backend in place of Frontend, and it implements only the subset of the Frontend functions needed by a backend. (Many other Frontend functions still exist, notably the wide range of things called by terminal.c providing platform-independent operations on the GUI terminal window.) The purpose of making it a vtable is that this opens up the possibility of creating a backend as an internal implementation detail of some other activity, by providing just that one backend with a custom Seat that implements the methods differently. For example, this refactoring should make it feasible to directly implement an SSH proxy type, aka the 'jump host' feature supported by OpenSSH, aka 'open a secondary SSH session in MAINCHAN_DIRECT_TCP mode, and then expose the main channel of that as the Socket for the primary connection'. (Which of course you can already do by spawning 'plink -nc' as a separate proxy process, but this would permit it in the _same_ process without anything getting confused.) I've centralised a full set of stub methods in misc.c for the new abstraction, which allows me to get rid of several annoying stubs in the previous code. Also, while I'm here, I've moved a lot of duplicated modalfatalbox() type functions from application main program files into wincons.c / uxcons.c, which I think saves duplication overall. (A minor visible effect is that the prefixes on those console-based fatal error messages will now be more consistent between applications.)
2018-10-11 18:58:42 +00:00
};
static Seat psftp_seat[1] = {{ &psftp_seat_vt }};
File transfer tools: sanitise remote filenames and stderr. This commit adds sanitisation to PSCP and PSFTP in the same style as I've just put it into Plink. This time, standard error is sanitised without reference to whether it's redirected (at least unless you give an override option), on the basis that where Plink is _sometimes_ an SSH transport for some other protocol, PSCP and PSFTP _always_ are. But also, the sanitiser is run over any remote filename sent by the server, substituting ? for any control characters it finds. That removes another avenue for the server to deliberately confuse the display. This commit fixes our bug 'pscp-unsanitised-server-output', aka the two notional 'vulnerabilities' CVE-2019-6109 and CVE-2019-6110. (Although we regard those in isolation as only bugs, not serious vulnerabilities, because their main threat was in hiding the evidence of a server having exploited other more serious vulns that we never had.)
2019-02-20 07:09:10 +00:00
/* ----------------------------------------------------------------------
* A nasty loop macro that lets me get an escape-sequence sanitised
* version of a string for display, and free it automatically
* afterwards.
*/
Make stripctrl_string take an existing StripCtrlChars. Now instead of making a StripCtrlChars just for that function call, it uses an existing one, pointing it at the output strbuf via stripctrl_retarget. This adds flexibility (now you can use the same convenient string- sanitising function with a StripCtrl configured in any way you like) and also saves pointless setting-up and tearing-down of identical sccs all the time. The existing call sites in PSCP and PSFTP now use a static StripCtrlChars instance that was made at program startup.
2019-03-09 16:03:40 +00:00
static StripCtrlChars *string_scc;
#define with_stripctrl(varname, input) \
for (char *varname = stripctrl_string(string_scc, input); varname; \
File transfer tools: sanitise remote filenames and stderr. This commit adds sanitisation to PSCP and PSFTP in the same style as I've just put it into Plink. This time, standard error is sanitised without reference to whether it's redirected (at least unless you give an override option), on the basis that where Plink is _sometimes_ an SSH transport for some other protocol, PSCP and PSFTP _always_ are. But also, the sanitiser is run over any remote filename sent by the server, substituting ? for any control characters it finds. That removes another avenue for the server to deliberately confuse the display. This commit fixes our bug 'pscp-unsanitised-server-output', aka the two notional 'vulnerabilities' CVE-2019-6109 and CVE-2019-6110. (Although we regard those in isolation as only bugs, not serious vulnerabilities, because their main threat was in hiding the evidence of a server having exploited other more serious vulns that we never had.)
2019-02-20 07:09:10 +00:00
sfree(varname), varname = NULL)
Clean up handling of the return value from sftp_find_request. In many places we simply enforce by assertion that it will match the request we sent out a moment ago: in fact it can also return NULL, so it makes more sense to report a proper error message if it doesn't return the expected value, and while we're at it, have that error message whatever message was helpfully left in fxp_error() by sftp_find_request when it failed. To do this, I've written a centralised function in psftp.c called sftp_wait_for_reply, which is handed a request that's just been sent out and deals with the mechanics of waiting for its reply, returning the reply when it arrives, and aborting with a sensible error if anything else arrives instead. The numerous sites in psftp.c which called sftp_find_request have all been rewritten to do this instead, and as a side effect they now look more sensible. The only other uses of sftp_find_request were in xfer_*load_gotpkt, which had to be tweaked in its own way. While I'm here, also fix memory management in sftp_find_request, which was freeing its input packet on some but not all error return paths. [originally from svn r9894]
2013-07-06 20:43:21 +00:00
/* ----------------------------------------------------------------------
* Manage sending requests and waiting for replies.
*/
struct sftp_packet *sftp_wait_for_reply(struct sftp_request *req)
{
struct sftp_packet *pktin;
struct sftp_request *rreq;
sftp_register(req);
pktin = sftp_recv();
New abstraction 'Seat', to pass to backends. This is a new vtable-based abstraction which is passed to a backend in place of Frontend, and it implements only the subset of the Frontend functions needed by a backend. (Many other Frontend functions still exist, notably the wide range of things called by terminal.c providing platform-independent operations on the GUI terminal window.) The purpose of making it a vtable is that this opens up the possibility of creating a backend as an internal implementation detail of some other activity, by providing just that one backend with a custom Seat that implements the methods differently. For example, this refactoring should make it feasible to directly implement an SSH proxy type, aka the 'jump host' feature supported by OpenSSH, aka 'open a secondary SSH session in MAINCHAN_DIRECT_TCP mode, and then expose the main channel of that as the Socket for the primary connection'. (Which of course you can already do by spawning 'plink -nc' as a separate proxy process, but this would permit it in the _same_ process without anything getting confused.) I've centralised a full set of stub methods in misc.c for the new abstraction, which allows me to get rid of several annoying stubs in the previous code. Also, while I'm here, I've moved a lot of duplicated modalfatalbox() type functions from application main program files into wincons.c / uxcons.c, which I think saves duplication overall. (A minor visible effect is that the prefixes on those console-based fatal error messages will now be more consistent between applications.)
2018-10-11 18:58:42 +00:00
if (pktin == NULL) {
seat_connection_fatal(
psftp_seat, "did not receive SFTP response packet from server");
}
Clean up handling of the return value from sftp_find_request. In many places we simply enforce by assertion that it will match the request we sent out a moment ago: in fact it can also return NULL, so it makes more sense to report a proper error message if it doesn't return the expected value, and while we're at it, have that error message whatever message was helpfully left in fxp_error() by sftp_find_request when it failed. To do this, I've written a centralised function in psftp.c called sftp_wait_for_reply, which is handed a request that's just been sent out and deals with the mechanics of waiting for its reply, returning the reply when it arrives, and aborting with a sensible error if anything else arrives instead. The numerous sites in psftp.c which called sftp_find_request have all been rewritten to do this instead, and as a side effect they now look more sensible. The only other uses of sftp_find_request were in xfer_*load_gotpkt, which had to be tweaked in its own way. While I'm here, also fix memory management in sftp_find_request, which was freeing its input packet on some but not all error return paths. [originally from svn r9894]
2013-07-06 20:43:21 +00:00
rreq = sftp_find_request(pktin);
New abstraction 'Seat', to pass to backends. This is a new vtable-based abstraction which is passed to a backend in place of Frontend, and it implements only the subset of the Frontend functions needed by a backend. (Many other Frontend functions still exist, notably the wide range of things called by terminal.c providing platform-independent operations on the GUI terminal window.) The purpose of making it a vtable is that this opens up the possibility of creating a backend as an internal implementation detail of some other activity, by providing just that one backend with a custom Seat that implements the methods differently. For example, this refactoring should make it feasible to directly implement an SSH proxy type, aka the 'jump host' feature supported by OpenSSH, aka 'open a secondary SSH session in MAINCHAN_DIRECT_TCP mode, and then expose the main channel of that as the Socket for the primary connection'. (Which of course you can already do by spawning 'plink -nc' as a separate proxy process, but this would permit it in the _same_ process without anything getting confused.) I've centralised a full set of stub methods in misc.c for the new abstraction, which allows me to get rid of several annoying stubs in the previous code. Also, while I'm here, I've moved a lot of duplicated modalfatalbox() type functions from application main program files into wincons.c / uxcons.c, which I think saves duplication overall. (A minor visible effect is that the prefixes on those console-based fatal error messages will now be more consistent between applications.)
2018-10-11 18:58:42 +00:00
if (rreq != req) {
seat_connection_fatal(
psftp_seat,
"unable to understand SFTP response packet from server: %s",
fxp_error());
}
Clean up handling of the return value from sftp_find_request. In many places we simply enforce by assertion that it will match the request we sent out a moment ago: in fact it can also return NULL, so it makes more sense to report a proper error message if it doesn't return the expected value, and while we're at it, have that error message whatever message was helpfully left in fxp_error() by sftp_find_request when it failed. To do this, I've written a centralised function in psftp.c called sftp_wait_for_reply, which is handed a request that's just been sent out and deals with the mechanics of waiting for its reply, returning the reply when it arrives, and aborting with a sensible error if anything else arrives instead. The numerous sites in psftp.c which called sftp_find_request have all been rewritten to do this instead, and as a side effect they now look more sensible. The only other uses of sftp_find_request were in xfer_*load_gotpkt, which had to be tweaked in its own way. While I'm here, also fix memory management in sftp_find_request, which was freeing its input packet on some but not all error return paths. [originally from svn r9894]
2013-07-06 20:43:21 +00:00
return pktin;
}
First stab at an SFTP client. Currently a Unixland testing app, not integrated into PuTTY. [originally from svn r938]
2001-02-23 18:21:44 +00:00
/* ----------------------------------------------------------------------
* Higher-level helper functions used in commands.
*/
/*
SFTP client now successfully handles cd, ls, get and put. [originally from svn r939]
2001-02-24 12:02:35 +00:00
* Attempt to canonify a pathname starting from the pwd. If
* canonification fails, at least fall back to returning a _valid_
* pathname (though it may be ugly, eg /home/simon/../foobar).
First stab at an SFTP client. Currently a Unixland testing app, not integrated into PuTTY. [originally from svn r938]
2001-02-23 18:21:44 +00:00
*/
Giant const-correctness patch of doom! Having found a lot of unfixed constness issues in recent development, I thought perhaps it was time to get proactive, so I compiled the whole codebase with -Wwrite-strings. That turned up a huge load of const problems, which I've fixed in this commit: the Unix build now goes cleanly through with -Wwrite-strings, and the Windows build is as close as I could get it (there are some lingering issues due to occasional Windows API functions like AcquireCredentialsHandle not having the right constness). Notable fallout beyond the purely mechanical changing of types: - the stuff saved by cmdline_save_param() is now explicitly dupstr()ed, and freed in cmdline_run_saved. - I couldn't make both string arguments to cmdline_process_param() const, because it intentionally writes to one of them in the case where it's the argument to -pw (in the vain hope of being at least slightly friendly to 'ps'), so elsewhere I had to temporarily dupstr() something for the sake of passing it to that function - I had to invent a silly parallel version of const_cmp() so I could pass const string literals in to lookup functions. - stripslashes() in pscp.c and psftp.c has the annoying strchr nature
2015-05-15 10:15:42 +00:00
char *canonify(const char *name)
Run entire source base through GNU indent to tidy up the varying coding styles of the various contributors! Woohoo! [originally from svn r1098]
2001-05-06 14:35:20 +00:00
{
SFTP client now successfully handles cd, ls, get and put. [originally from svn r939]
2001-02-24 12:02:35 +00:00
char *fullname, *canonname;
First phase of SFTP re-engineering. Each base-level fxp_* function has been split into a send half and a receive half, so that callers can set several requests in motion at a time and deal with the responses in whatever order they arrive. [originally from svn r3318]
2003-06-29 14:26:09 +00:00
struct sftp_packet *pktin;
Clean up handling of the return value from sftp_find_request. In many places we simply enforce by assertion that it will match the request we sent out a moment ago: in fact it can also return NULL, so it makes more sense to report a proper error message if it doesn't return the expected value, and while we're at it, have that error message whatever message was helpfully left in fxp_error() by sftp_find_request when it failed. To do this, I've written a centralised function in psftp.c called sftp_wait_for_reply, which is handed a request that's just been sent out and deals with the mechanics of waiting for its reply, returning the reply when it arrives, and aborting with a sensible error if anything else arrives instead. The numerous sites in psftp.c which called sftp_find_request have all been rewritten to do this instead, and as a side effect they now look more sensible. The only other uses of sftp_find_request were in xfer_*load_gotpkt, which had to be tweaked in its own way. While I'm here, also fix memory management in sftp_find_request, which was freeing its input packet on some but not all error return paths. [originally from svn r9894]
2013-07-06 20:43:21 +00:00
struct sftp_request *req;
psftp now works as part of the PuTTY suite [originally from svn r940]
2001-02-24 16:08:56 +00:00
SFTP client now successfully handles cd, ls, get and put. [originally from svn r939]
2001-02-24 12:02:35 +00:00
if (name[0] == '/') {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
fullname = dupstr(name);
SFTP client now successfully handles cd, ls, get and put. [originally from svn r939]
2001-02-24 12:02:35 +00:00
} else {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
const char *slash;
if (pwd[strlen(pwd) - 1] == '/')
slash = "";
else
slash = "/";
Make dupcat() into a variadic macro. Up until now, it's been a variadic _function_, whose argument list consists of 'const char *' ASCIZ strings to concatenate, terminated by one containing a null pointer. Now, that function is dupcat_fn(), and it's wrapped by a C99 variadic _macro_ called dupcat(), which automatically suffixes the null-pointer terminating argument. This has three benefits. Firstly, it's just less effort at every call site. Secondly, it protects against the risk of accidentally leaving off the NULL, causing arbitrary words of stack memory to be dereferenced as char pointers. And thirdly, it protects against the more subtle risk of writing a bare 'NULL' as the terminating argument, instead of casting it explicitly to a pointer. That last one is necessary because C permits the macro NULL to expand to an integer constant such as 0, so NULL by itself may not have pointer type, and worse, it may not be marshalled in a variadic argument list in the same way as a pointer. (For example, on a 64-bit machine it might only occupy 32 bits. And yet, on another 64-bit platform, it might work just fine, so that you don't notice the mistake!) I was inspired to do this by happening to notice one of those bare NULL terminators, and thinking I'd better check if there were any more. Turned out there were quite a few. Now there are none.
2019-10-14 18:42:37 +00:00
fullname = dupcat(pwd, slash, name);
SFTP client now successfully handles cd, ls, get and put. [originally from svn r939]
2001-02-24 12:02:35 +00:00
}
psftp now works as part of the PuTTY suite [originally from svn r940]
2001-02-24 16:08:56 +00:00
Clean up handling of the return value from sftp_find_request. In many places we simply enforce by assertion that it will match the request we sent out a moment ago: in fact it can also return NULL, so it makes more sense to report a proper error message if it doesn't return the expected value, and while we're at it, have that error message whatever message was helpfully left in fxp_error() by sftp_find_request when it failed. To do this, I've written a centralised function in psftp.c called sftp_wait_for_reply, which is handed a request that's just been sent out and deals with the mechanics of waiting for its reply, returning the reply when it arrives, and aborting with a sensible error if anything else arrives instead. The numerous sites in psftp.c which called sftp_find_request have all been rewritten to do this instead, and as a side effect they now look more sensible. The only other uses of sftp_find_request were in xfer_*load_gotpkt, which had to be tweaked in its own way. While I'm here, also fix memory management in sftp_find_request, which was freeing its input packet on some but not all error return paths. [originally from svn r9894]
2013-07-06 20:43:21 +00:00
req = fxp_realpath_send(fullname);
pktin = sftp_wait_for_reply(req);
canonname = fxp_realpath_recv(pktin, req);
psftp now works as part of the PuTTY suite [originally from svn r940]
2001-02-24 16:08:56 +00:00
SFTP client now successfully handles cd, ls, get and put. [originally from svn r939]
2001-02-24 12:02:35 +00:00
if (canonname) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
sfree(fullname);
return canonname;
Moderately evil workaround to compensate for a variation in behaviour of FXP_REALPATH. (Specifically, BSD and GNU realpath(3) disagree over whether to return success when computing the realpath for a putative new file to be created in a valid directory. There's no way we can tell from (say) the OpenSSH version string because OpenSSH might have been compiled to use the local realpath _or_ its own nonbroken one.) [originally from svn r953]
2001-02-26 16:39:15 +00:00
} else {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
/*
* Attempt number 2. Some FXP_REALPATH implementations
* (glibc-based ones, in particular) require the _whole_
* path to point to something that exists, whereas others
* (BSD-based) only require all but the last component to
* exist. So if the first call failed, we should strip off
* everything from the last slash onwards and try again,
* then put the final component back on.
*
* Special cases:
*
* - if the last component is "/." or "/..", then we don't
* bother trying this because there's no way it can work.
*
* - if the thing actually ends with a "/", we remove it
* before we start. Except if the string is "/" itself
* (although I can't see why we'd have got here if so,
* because surely "/" would have worked the first
* time?), in which case we don't bother.
*
* - if there's no slash in the string at all, give up in
* confusion (we expect at least one because of the way
* we constructed the string).
*/
int i;
char *returnname;
i = strlen(fullname);
if (i > 2 && fullname[i - 1] == '/')
fullname[--i] = '\0'; /* strip trailing / unless at pos 0 */
while (i > 0 && fullname[--i] != '/');
/*
* Give up on special cases.
*/
if (fullname[i] != '/' || /* no slash at all */
!strcmp(fullname + i, "/.") || /* ends in /. */
!strcmp(fullname + i, "/..") || /* ends in /.. */
!strcmp(fullname, "/")) {
return fullname;
}
/*
* Now i points at the slash. Deal with the final special
* case i==0 (ie the whole path was "/nonexistentfile").
*/
fullname[i] = '\0'; /* separate the string */
if (i == 0) {
req = fxp_realpath_send("/");
} else {
req = fxp_realpath_send(fullname);
}
pktin = sftp_wait_for_reply(req);
canonname = fxp_realpath_recv(pktin, req);
if (!canonname) {
/* Even that failed. Restore our best guess at the
* constructed filename and give up */
fullname[i] = '/'; /* restore slash and last component */
return fullname;
}
/*
* We have a canonical name for all but the last path
* component. Concatenate the last component and return.
*/
returnname = dupcat(canonname,
Make dupcat() into a variadic macro. Up until now, it's been a variadic _function_, whose argument list consists of 'const char *' ASCIZ strings to concatenate, terminated by one containing a null pointer. Now, that function is dupcat_fn(), and it's wrapped by a C99 variadic _macro_ called dupcat(), which automatically suffixes the null-pointer terminating argument. This has three benefits. Firstly, it's just less effort at every call site. Secondly, it protects against the risk of accidentally leaving off the NULL, causing arbitrary words of stack memory to be dereferenced as char pointers. And thirdly, it protects against the more subtle risk of writing a bare 'NULL' as the terminating argument, instead of casting it explicitly to a pointer. That last one is necessary because C permits the macro NULL to expand to an integer constant such as 0, so NULL by itself may not have pointer type, and worse, it may not be marshalled in a variadic argument list in the same way as a pointer. (For example, on a 64-bit machine it might only occupy 32 bits. And yet, on another 64-bit platform, it might work just fine, so that you don't notice the mistake!) I was inspired to do this by happening to notice one of those bare NULL terminators, and thinking I'd better check if there were any more. Turned out there were quite a few. Now there are none.
2019-10-14 18:42:37 +00:00
(strendswith(canonname, "/") ? "" : "/"),
fullname + i + 1);
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
sfree(fullname);
sfree(canonname);
return returnname;
Moderately evil workaround to compensate for a variation in behaviour of FXP_REALPATH. (Specifically, BSD and GNU realpath(3) disagree over whether to return success when computing the realpath for a putative new file to be created in a valid directory. There's no way we can tell from (say) the OpenSSH version string because OpenSSH might have been compiled to use the local realpath _or_ its own nonbroken one.) [originally from svn r953]
2001-02-26 16:39:15 +00:00
}
First stab at an SFTP client. Currently a Unixland testing app, not integrated into PuTTY. [originally from svn r938]
2001-02-23 18:21:44 +00:00
}
Support for recursive file transfer in PSFTP. [originally from svn r4990] [this svn revision also touched putty-wishlist]
2004-12-16 16:37:37 +00:00
static int bare_name_compare(const void *av, const void *bv)
Add the `pwd' command in PSFTP. [originally from svn r1262]
2001-09-09 16:31:26 +00:00
{
Support for recursive file transfer in PSFTP. [originally from svn r4990] [this svn revision also touched putty-wishlist]
2004-12-16 16:37:37 +00:00
const char **a = (const char **) av;
const char **b = (const char **) bv;
return strcmp(*a, *b);
Add the `pwd' command in PSFTP. [originally from svn r1262]
2001-09-09 16:31:26 +00:00
}
Localise "not connected to a host" messages. [originally from svn r5060]
2005-01-01 16:43:19 +00:00
static void not_connected(void)
{
printf("psftp: not connected to a host; use \"open host.name\"\n");
}
Support for recursive file transfer in PSFTP. [originally from svn r4990] [this svn revision also touched putty-wishlist]
2004-12-16 16:37:37 +00:00
/* ----------------------------------------------------------------------
* The meat of the `get' and `put' commands.
First stab at an SFTP client. Currently a Unixland testing app, not integrated into PuTTY. [originally from svn r938]
2001-02-23 18:21:44 +00:00
*/
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
bool sftp_get_file(char *fname, char *outfname, bool recurse, bool restart)
Run entire source base through GNU indent to tidy up the varying coding styles of the various contributors! Woohoo! [originally from svn r1098]
2001-05-06 14:35:20 +00:00
{
First stab at an SFTP client. Currently a Unixland testing app, not integrated into PuTTY. [originally from svn r938]
2001-02-23 18:21:44 +00:00
struct fxp_handle *fh;
First phase of SFTP re-engineering. Each base-level fxp_* function has been split into a send half and a receive half, so that callers can set several requests in motion at a time and deal with the responses in whatever order they arrive. [originally from svn r3318]
2003-06-29 14:26:09 +00:00
struct sftp_packet *pktin;
Clean up handling of the return value from sftp_find_request. In many places we simply enforce by assertion that it will match the request we sent out a moment ago: in fact it can also return NULL, so it makes more sense to report a proper error message if it doesn't return the expected value, and while we're at it, have that error message whatever message was helpfully left in fxp_error() by sftp_find_request when it failed. To do this, I've written a centralised function in psftp.c called sftp_wait_for_reply, which is handed a request that's just been sent out and deals with the mechanics of waiting for its reply, returning the reply when it arrives, and aborting with a sensible error if anything else arrives instead. The numerous sites in psftp.c which called sftp_find_request have all been rewritten to do this instead, and as a side effect they now look more sensible. The only other uses of sftp_find_request were in xfer_*load_gotpkt, which had to be tweaked in its own way. While I'm here, also fix memory management in sftp_find_request, which was freeing its input packet on some but not all error return paths. [originally from svn r9894]
2013-07-06 20:43:21 +00:00
struct sftp_request *req;
First cut at speeding up SFTP. Generic download-management code in sftp.c, and psftp.c now uses that instead of going it alone. Should in principle be easily installed in PSCP as well, but I haven't done it yet; also it only handles downloads, not uploads, and finally it doesn't yet properly calculate the correct number of parallel requests to queue. Still, it's a start, and in my own tests it seemed to perform as expected (download speed suddenly became roughly what you'd expect from the available bandwidth, and decreased by roughly the expected number of round-trip times). [originally from svn r3468]
2003-09-27 17:52:34 +00:00
struct fxp_xfer *xfer;
Adopt C99 <stdint.h> integer types. The annoying int64.h is completely retired, since C99 guarantees a 64-bit integer type that you can actually treat like an ordinary integer. Also, I've replaced the local typedefs uint32 and word32 (scattered through different parts of the crypto code) with the standard uint32_t.
2018-10-26 22:08:58 +00:00
uint64_t offset;
Large file support for psftp and pscp on both Windows and Unix. On Unix we set _FILE_OFFSET_BITS to 64 on the compiler command line (via mkfiles.pl), and on Windows we use SetFilePointer and GetFileSize to cope with 64-bit sizes where possible. Not tested on Win9x. [originally from svn r6783]
2006-08-12 15:20:19 +00:00
WFile *file;
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
bool toret, shown_err = false;
Propagate file permissions in both directions in Unix pscp and psftp. I think I have to consider this to be a separate but related change to the wishlist item 'pscp-filemodes'; that was written before the Unix port existed, and referred to the ability to configure the permissions used for files copied from Windows to Unix - which is still not done. [originally from svn r9260]
2011-08-11 17:59:30 +00:00
struct fxp_attrs attrs;
First stab at an SFTP client. Currently a Unixland testing app, not integrated into PuTTY. [originally from svn r938]
2001-02-23 18:21:44 +00:00
Support for recursive file transfer in PSFTP. [originally from svn r4990] [this svn revision also touched putty-wishlist]
2004-12-16 16:37:37 +00:00
/*
* In recursive mode, see if we're dealing with a directory.
* (If we're not in recursive mode, we need not even check: the
* subsequent FXP_OPEN will return a usable error message.)
*/
I've decided that trying to do wildcards in PSFTP as a special case of directory recursion was a strategic error: it obfuscates sftp_{get,put}_file(), and also it makes it very hard to handle subdirectory wildcards such as `foo/*'. Accordingly, here's a completely different approach, in which sftp_{get,put}_file() are still responsible for directory recursion, but wildcards are expanded in sftp_general_{get,put}() before being passed thereto. Subdirectory wildcards are now handled consistently across Unix, Windows and the remote server. [originally from svn r5045]
2004-12-30 13:51:37 +00:00
if (recurse) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
bool result;
Allow PSFTP to be run with no arguments, in which case it enters the command-line state but all commands are disallowed except `open host.name'. The idea is to provide marginal extra niceness for people who double-click the icon without realising it's a cmdline app. [originally from svn r1480]
2001-12-13 18:42:34 +00:00
Clean up handling of the return value from sftp_find_request. In many places we simply enforce by assertion that it will match the request we sent out a moment ago: in fact it can also return NULL, so it makes more sense to report a proper error message if it doesn't return the expected value, and while we're at it, have that error message whatever message was helpfully left in fxp_error() by sftp_find_request when it failed. To do this, I've written a centralised function in psftp.c called sftp_wait_for_reply, which is handed a request that's just been sent out and deals with the mechanics of waiting for its reply, returning the reply when it arrives, and aborting with a sensible error if anything else arrives instead. The numerous sites in psftp.c which called sftp_find_request have all been rewritten to do this instead, and as a side effect they now look more sensible. The only other uses of sftp_find_request were in xfer_*load_gotpkt, which had to be tweaked in its own way. While I'm here, also fix memory management in sftp_find_request, which was freeing its input packet on some but not all error return paths. [originally from svn r9894]
2013-07-06 20:43:21 +00:00
req = fxp_stat_send(fname);
pktin = sftp_wait_for_reply(req);
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
result = fxp_stat_recv(pktin, req, &attrs);
if (result &&
(attrs.flags & SSH_FILEXFER_ATTR_PERMISSIONS) &&
(attrs.permissions & 0040000)) {
struct fxp_handle *dirhandle;
size_t nnames, namesize;
struct fxp_name **ournames;
struct fxp_names *names;
int i;
/*
* First, attempt to create the destination directory,
* unless it already exists.
*/
if (file_type(outfname) != FILE_TYPE_DIRECTORY &&
!create_directory(outfname)) {
File transfer tools: sanitise remote filenames and stderr. This commit adds sanitisation to PSCP and PSFTP in the same style as I've just put it into Plink. This time, standard error is sanitised without reference to whether it's redirected (at least unless you give an override option), on the basis that where Plink is _sometimes_ an SSH transport for some other protocol, PSCP and PSFTP _always_ are. But also, the sanitiser is run over any remote filename sent by the server, substituting ? for any control characters it finds. That removes another avenue for the server to deliberately confuse the display. This commit fixes our bug 'pscp-unsanitised-server-output', aka the two notional 'vulnerabilities' CVE-2019-6109 and CVE-2019-6110. (Although we regard those in isolation as only bugs, not serious vulnerabilities, because their main threat was in hiding the evidence of a server having exploited other more serious vulns that we never had.)
2019-02-20 07:09:10 +00:00
with_stripctrl(san, outfname)
printf("%s: Cannot create directory\n", san);
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
return false;
}
First stab at an SFTP client. Currently a Unixland testing app, not integrated into PuTTY. [originally from svn r938]
2001-02-23 18:21:44 +00:00
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
/*
* Now get the list of filenames in the remote
* directory.
*/
Clean up handling of the return value from sftp_find_request. In many places we simply enforce by assertion that it will match the request we sent out a moment ago: in fact it can also return NULL, so it makes more sense to report a proper error message if it doesn't return the expected value, and while we're at it, have that error message whatever message was helpfully left in fxp_error() by sftp_find_request when it failed. To do this, I've written a centralised function in psftp.c called sftp_wait_for_reply, which is handed a request that's just been sent out and deals with the mechanics of waiting for its reply, returning the reply when it arrives, and aborting with a sensible error if anything else arrives instead. The numerous sites in psftp.c which called sftp_find_request have all been rewritten to do this instead, and as a side effect they now look more sensible. The only other uses of sftp_find_request were in xfer_*load_gotpkt, which had to be tweaked in its own way. While I'm here, also fix memory management in sftp_find_request, which was freeing its input packet on some but not all error return paths. [originally from svn r9894]
2013-07-06 20:43:21 +00:00
req = fxp_opendir_send(fname);
pktin = sftp_wait_for_reply(req);
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
dirhandle = fxp_opendir_recv(pktin, req);
Support for recursive file transfer in PSFTP. [originally from svn r4990] [this svn revision also touched putty-wishlist]
2004-12-16 16:37:37 +00:00
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
if (!dirhandle) {
File transfer tools: sanitise remote filenames and stderr. This commit adds sanitisation to PSCP and PSFTP in the same style as I've just put it into Plink. This time, standard error is sanitised without reference to whether it's redirected (at least unless you give an override option), on the basis that where Plink is _sometimes_ an SSH transport for some other protocol, PSCP and PSFTP _always_ are. But also, the sanitiser is run over any remote filename sent by the server, substituting ? for any control characters it finds. That removes another avenue for the server to deliberately confuse the display. This commit fixes our bug 'pscp-unsanitised-server-output', aka the two notional 'vulnerabilities' CVE-2019-6109 and CVE-2019-6110. (Although we regard those in isolation as only bugs, not serious vulnerabilities, because their main threat was in hiding the evidence of a server having exploited other more serious vulns that we never had.)
2019-02-20 07:09:10 +00:00
with_stripctrl(san, fname)
printf("%s: unable to open directory: %s\n",
san, fxp_error());
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
return false;
}
nnames = namesize = 0;
ournames = NULL;
while (1) {
int i;
req = fxp_readdir_send(dirhandle);
Clean up handling of the return value from sftp_find_request. In many places we simply enforce by assertion that it will match the request we sent out a moment ago: in fact it can also return NULL, so it makes more sense to report a proper error message if it doesn't return the expected value, and while we're at it, have that error message whatever message was helpfully left in fxp_error() by sftp_find_request when it failed. To do this, I've written a centralised function in psftp.c called sftp_wait_for_reply, which is handed a request that's just been sent out and deals with the mechanics of waiting for its reply, returning the reply when it arrives, and aborting with a sensible error if anything else arrives instead. The numerous sites in psftp.c which called sftp_find_request have all been rewritten to do this instead, and as a side effect they now look more sensible. The only other uses of sftp_find_request were in xfer_*load_gotpkt, which had to be tweaked in its own way. While I'm here, also fix memory management in sftp_find_request, which was freeing its input packet on some but not all error return paths. [originally from svn r9894]
2013-07-06 20:43:21 +00:00
pktin = sftp_wait_for_reply(req);
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
names = fxp_readdir_recv(pktin, req);
Support for recursive file transfer in PSFTP. [originally from svn r4990] [this svn revision also touched putty-wishlist]
2004-12-16 16:37:37 +00:00
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
if (names == NULL) {
if (fxp_error_type() == SSH_FX_EOF)
break;
File transfer tools: sanitise remote filenames and stderr. This commit adds sanitisation to PSCP and PSFTP in the same style as I've just put it into Plink. This time, standard error is sanitised without reference to whether it's redirected (at least unless you give an override option), on the basis that where Plink is _sometimes_ an SSH transport for some other protocol, PSCP and PSFTP _always_ are. But also, the sanitiser is run over any remote filename sent by the server, substituting ? for any control characters it finds. That removes another avenue for the server to deliberately confuse the display. This commit fixes our bug 'pscp-unsanitised-server-output', aka the two notional 'vulnerabilities' CVE-2019-6109 and CVE-2019-6110. (Although we regard those in isolation as only bugs, not serious vulnerabilities, because their main threat was in hiding the evidence of a server having exploited other more serious vulns that we never had.)
2019-02-20 07:09:10 +00:00
with_stripctrl(san, fname)
printf("%s: reading directory: %s\n",
san, fxp_error());
Fix a couple of code paths on which, if fxp_readdir returned an error, we would return without first closing the directory handle we had used as an argument. [originally from svn r9913]
2013-07-11 17:24:44 +00:00
req = fxp_close_send(dirhandle);
pktin = sftp_wait_for_reply(req);
fxp_close_recv(pktin, req);
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
sfree(ournames);
return false;
}
if (names->nnames == 0) {
fxp_free_names(names);
break;
}
New array-growing macros: sgrowarray and sgrowarrayn. The idea of these is that they centralise the common idiom along the lines of if (logical_array_len >= physical_array_size) { physical_array_size = logical_array_len * 5 / 4 + 256; array = sresize(array, physical_array_size, ElementType); } which happens at a zillion call sites throughout this code base, with different random choices of the geometric factor and additive constant, sometimes forgetting them completely, and generally doing a lot of repeated work. The new macro sgrowarray(array,size,n) has the semantics: here are the array pointer and its physical size for you to modify, now please ensure that the nth element exists, so I can write into it. And sgrowarrayn(array,size,n,m) is the same except that it ensures that the array has size at least n+m (so sgrowarray is just the special case where m=1). Now that this is a single centralised implementation that will be used everywhere, I've also gone to more effort in the implementation, with careful overflow checks that would have been painful to put at all the previous call sites. This commit also switches over every use of sresize(), apart from a few where I really didn't think it would gain anything. A consequence of that is that a lot of array-size variables have to have their types changed to size_t, because the macros require that (they address-take the size to pass to the underlying function).
2019-02-28 20:07:30 +00:00
sgrowarrayn(ournames, namesize, nnames, names->nnames);
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
for (i = 0; i < names->nnames; i++)
if (strcmp(names->names[i].filename, ".") &&
strcmp(names->names[i].filename, "..")) {
if (!vet_filename(names->names[i].filename)) {
File transfer tools: sanitise remote filenames and stderr. This commit adds sanitisation to PSCP and PSFTP in the same style as I've just put it into Plink. This time, standard error is sanitised without reference to whether it's redirected (at least unless you give an override option), on the basis that where Plink is _sometimes_ an SSH transport for some other protocol, PSCP and PSFTP _always_ are. But also, the sanitiser is run over any remote filename sent by the server, substituting ? for any control characters it finds. That removes another avenue for the server to deliberately confuse the display. This commit fixes our bug 'pscp-unsanitised-server-output', aka the two notional 'vulnerabilities' CVE-2019-6109 and CVE-2019-6110. (Although we regard those in isolation as only bugs, not serious vulnerabilities, because their main threat was in hiding the evidence of a server having exploited other more serious vulns that we never had.)
2019-02-20 07:09:10 +00:00
with_stripctrl(san, names->names[i].filename)
printf("ignoring potentially dangerous server-"
"supplied filename '%s'\n", san);
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
} else {
ournames[nnames++] =
fxp_dup_name(&names->names[i]);
}
}
fxp_free_names(names);
}
req = fxp_close_send(dirhandle);
Clean up handling of the return value from sftp_find_request. In many places we simply enforce by assertion that it will match the request we sent out a moment ago: in fact it can also return NULL, so it makes more sense to report a proper error message if it doesn't return the expected value, and while we're at it, have that error message whatever message was helpfully left in fxp_error() by sftp_find_request when it failed. To do this, I've written a centralised function in psftp.c called sftp_wait_for_reply, which is handed a request that's just been sent out and deals with the mechanics of waiting for its reply, returning the reply when it arrives, and aborting with a sensible error if anything else arrives instead. The numerous sites in psftp.c which called sftp_find_request have all been rewritten to do this instead, and as a side effect they now look more sensible. The only other uses of sftp_find_request were in xfer_*load_gotpkt, which had to be tweaked in its own way. While I'm here, also fix memory management in sftp_find_request, which was freeing its input packet on some but not all error return paths. [originally from svn r9894]
2013-07-06 20:43:21 +00:00
pktin = sftp_wait_for_reply(req);
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
fxp_close_recv(pktin, req);
/*
* Sort the names into a clear order. This ought to
* make things more predictable when we're doing a
* reget of the same directory, just in case two
* readdirs on the same remote directory return a
* different order.
*/
It's not actually legal by the C standard to call qsort with a null array pointer, _even_ if you're asking it to sort zero elements so that in principle it should never dereference that pointer. Fix the four instances in PSCP/PSFTP where this was previously occurring. [originally from svn r9912]
2013-07-11 17:24:39 +00:00
if (nnames > 0)
qsort(ournames, nnames, sizeof(*ournames), sftp_name_compare);
Support for recursive file transfer in PSFTP. [originally from svn r4990] [this svn revision also touched putty-wishlist]
2004-12-16 16:37:37 +00:00
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
/*
* If we're in restart mode, find the last filename on
* this list that already exists. We may have to do a
* reget on _that_ file, but shouldn't have to do
* anything on the previous files.
*
* If none of them exists, of course, we start at 0.
*/
i = 0;
When the comments say `if we're in restart mode', the code in question should actually be conditional on restart mode! [originally from svn r7438]
2007-04-02 08:44:00 +00:00
if (restart) {
while (i < nnames) {
char *nextoutfname;
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
bool nonexistent;
Remove redundant null checks for arguments to sftp_{get,put}_file which are (a) never NULL anyway, and (b) have already been dereferenced by the time we make those checks so it would be too late if they were. [originally from svn r9906]
2013-07-11 17:24:10 +00:00
nextoutfname = dir_file_cat(outfname,
ournames[i]->filename);
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
nonexistent = (file_type(nextoutfname) ==
FILE_TYPE_NONEXISTENT);
When the comments say `if we're in restart mode', the code in question should actually be conditional on restart mode! [originally from svn r7438]
2007-04-02 08:44:00 +00:00
sfree(nextoutfname);
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
if (nonexistent)
When the comments say `if we're in restart mode', the code in question should actually be conditional on restart mode! [originally from svn r7438]
2007-04-02 08:44:00 +00:00
break;
i++;
}
if (i > 0)
i--;
}
Support for recursive file transfer in PSFTP. [originally from svn r4990] [this svn revision also touched putty-wishlist]
2004-12-16 16:37:37 +00:00
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
/*
* Now we're ready to recurse. Starting at ournames[i]
* and continuing on to the end of the list, we
* construct a new source and target file name, and
* call sftp_get_file again.
*/
for (; i < nnames; i++) {
char *nextfname, *nextoutfname;
bool retd;
Make dupcat() into a variadic macro. Up until now, it's been a variadic _function_, whose argument list consists of 'const char *' ASCIZ strings to concatenate, terminated by one containing a null pointer. Now, that function is dupcat_fn(), and it's wrapped by a C99 variadic _macro_ called dupcat(), which automatically suffixes the null-pointer terminating argument. This has three benefits. Firstly, it's just less effort at every call site. Secondly, it protects against the risk of accidentally leaving off the NULL, causing arbitrary words of stack memory to be dereferenced as char pointers. And thirdly, it protects against the more subtle risk of writing a bare 'NULL' as the terminating argument, instead of casting it explicitly to a pointer. That last one is necessary because C permits the macro NULL to expand to an integer constant such as 0, so NULL by itself may not have pointer type, and worse, it may not be marshalled in a variadic argument list in the same way as a pointer. (For example, on a 64-bit machine it might only occupy 32 bits. And yet, on another 64-bit platform, it might work just fine, so that you don't notice the mistake!) I was inspired to do this by happening to notice one of those bare NULL terminators, and thinking I'd better check if there were any more. Turned out there were quite a few. Now there are none.
2019-10-14 18:42:37 +00:00
nextfname = dupcat(fname, "/", ournames[i]->filename);
Remove redundant null checks for arguments to sftp_{get,put}_file which are (a) never NULL anyway, and (b) have already been dereferenced by the time we make those checks so it would be too late if they were. [originally from svn r9906]
2013-07-11 17:24:10 +00:00
nextoutfname = dir_file_cat(outfname, ournames[i]->filename);
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
retd = sftp_get_file(
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
nextfname, nextoutfname, recurse, restart);
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
restart = false; /* after first partial file, do full */
sfree(nextoutfname);
sfree(nextfname);
if (!retd) {
for (i = 0; i < nnames; i++) {
fxp_free_name(ournames[i]);
}
sfree(ournames);
return false;
}
}
/*
* Done this recursion level. Free everything.
*/
for (i = 0; i < nnames; i++) {
fxp_free_name(ournames[i]);
}
sfree(ournames);
return true;
}
First stab at an SFTP client. Currently a Unixland testing app, not integrated into PuTTY. [originally from svn r938]
2001-02-23 18:21:44 +00:00
}
Clean up handling of the return value from sftp_find_request. In many places we simply enforce by assertion that it will match the request we sent out a moment ago: in fact it can also return NULL, so it makes more sense to report a proper error message if it doesn't return the expected value, and while we're at it, have that error message whatever message was helpfully left in fxp_error() by sftp_find_request when it failed. To do this, I've written a centralised function in psftp.c called sftp_wait_for_reply, which is handed a request that's just been sent out and deals with the mechanics of waiting for its reply, returning the reply when it arrives, and aborting with a sensible error if anything else arrives instead. The numerous sites in psftp.c which called sftp_find_request have all been rewritten to do this instead, and as a side effect they now look more sensible. The only other uses of sftp_find_request were in xfer_*load_gotpkt, which had to be tweaked in its own way. While I'm here, also fix memory management in sftp_find_request, which was freeing its input packet on some but not all error return paths. [originally from svn r9894]
2013-07-06 20:43:21 +00:00
req = fxp_stat_send(fname);
pktin = sftp_wait_for_reply(req);
if (!fxp_stat_recv(pktin, req, &attrs))
Propagate file permissions in both directions in Unix pscp and psftp. I think I have to consider this to be a separate but related change to the wishlist item 'pscp-filemodes'; that was written before the Unix port existed, and referred to the ability to configure the permissions used for files copied from Windows to Unix - which is still not done. [originally from svn r9260]
2011-08-11 17:59:30 +00:00
attrs.flags = 0;
Clean up handling of the return value from sftp_find_request. In many places we simply enforce by assertion that it will match the request we sent out a moment ago: in fact it can also return NULL, so it makes more sense to report a proper error message if it doesn't return the expected value, and while we're at it, have that error message whatever message was helpfully left in fxp_error() by sftp_find_request when it failed. To do this, I've written a centralised function in psftp.c called sftp_wait_for_reply, which is handed a request that's just been sent out and deals with the mechanics of waiting for its reply, returning the reply when it arrives, and aborting with a sensible error if anything else arrives instead. The numerous sites in psftp.c which called sftp_find_request have all been rewritten to do this instead, and as a side effect they now look more sensible. The only other uses of sftp_find_request were in xfer_*load_gotpkt, which had to be tweaked in its own way. While I'm here, also fix memory management in sftp_find_request, which was freeing its input packet on some but not all error return paths. [originally from svn r9894]
2013-07-06 20:43:21 +00:00
req = fxp_open_send(fname, SSH_FXF_READ, NULL);
pktin = sftp_wait_for_reply(req);
fh = fxp_open_recv(pktin, req);
First phase of SFTP re-engineering. Each base-level fxp_* function has been split into a send half and a receive half, so that callers can set several requests in motion at a time and deal with the responses in whatever order they arrive. [originally from svn r3318]
2003-06-29 14:26:09 +00:00
First stab at an SFTP client. Currently a Unixland testing app, not integrated into PuTTY. [originally from svn r938]
2001-02-23 18:21:44 +00:00
if (!fh) {
File transfer tools: sanitise remote filenames and stderr. This commit adds sanitisation to PSCP and PSFTP in the same style as I've just put it into Plink. This time, standard error is sanitised without reference to whether it's redirected (at least unless you give an override option), on the basis that where Plink is _sometimes_ an SSH transport for some other protocol, PSCP and PSFTP _always_ are. But also, the sanitiser is run over any remote filename sent by the server, substituting ? for any control characters it finds. That removes another avenue for the server to deliberately confuse the display. This commit fixes our bug 'pscp-unsanitised-server-output', aka the two notional 'vulnerabilities' CVE-2019-6109 and CVE-2019-6110. (Although we regard those in isolation as only bugs, not serious vulnerabilities, because their main threat was in hiding the evidence of a server having exploited other more serious vulns that we never had.)
2019-02-20 07:09:10 +00:00
with_stripctrl(san, fname)
printf("%s: open for read: %s\n", san, fxp_error());
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
return false;
First stab at an SFTP client. Currently a Unixland testing app, not integrated into PuTTY. [originally from svn r938]
2001-02-23 18:21:44 +00:00
}
More upgrades to psftp: it now supports mv, chmod, reget and reput. [originally from svn r1203]
2001-08-26 11:35:11 +00:00
if (restart) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
file = open_existing_wfile(outfname, NULL);
More upgrades to psftp: it now supports mv, chmod, reget and reput. [originally from svn r1203]
2001-08-26 11:35:11 +00:00
} else {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
file = open_new_file(outfname, GET_PERMISSIONS(attrs, -1));
More upgrades to psftp: it now supports mv, chmod, reget and reput. [originally from svn r1203]
2001-08-26 11:35:11 +00:00
}
Large file support for psftp and pscp on both Windows and Unix. On Unix we set _FILE_OFFSET_BITS to 64 on the compiler command line (via mkfiles.pl), and on Windows we use SetFilePointer and GetFileSize to cope with 64-bit sizes where possible. Not tested on Win9x. [originally from svn r6783]
2006-08-12 15:20:19 +00:00
if (!file) {
File transfer tools: sanitise remote filenames and stderr. This commit adds sanitisation to PSCP and PSFTP in the same style as I've just put it into Plink. This time, standard error is sanitised without reference to whether it's redirected (at least unless you give an override option), on the basis that where Plink is _sometimes_ an SSH transport for some other protocol, PSCP and PSFTP _always_ are. But also, the sanitiser is run over any remote filename sent by the server, substituting ? for any control characters it finds. That removes another avenue for the server to deliberately confuse the display. This commit fixes our bug 'pscp-unsanitised-server-output', aka the two notional 'vulnerabilities' CVE-2019-6109 and CVE-2019-6110. (Although we regard those in isolation as only bugs, not serious vulnerabilities, because their main threat was in hiding the evidence of a server having exploited other more serious vulns that we never had.)
2019-02-20 07:09:10 +00:00
with_stripctrl(san, outfname)
printf("local: unable to open %s\n", san);
First phase of SFTP re-engineering. Each base-level fxp_* function has been split into a send half and a receive half, so that callers can set several requests in motion at a time and deal with the responses in whatever order they arrive. [originally from svn r3318]
2003-06-29 14:26:09 +00:00
Clean up handling of the return value from sftp_find_request. In many places we simply enforce by assertion that it will match the request we sent out a moment ago: in fact it can also return NULL, so it makes more sense to report a proper error message if it doesn't return the expected value, and while we're at it, have that error message whatever message was helpfully left in fxp_error() by sftp_find_request when it failed. To do this, I've written a centralised function in psftp.c called sftp_wait_for_reply, which is handed a request that's just been sent out and deals with the mechanics of waiting for its reply, returning the reply when it arrives, and aborting with a sensible error if anything else arrives instead. The numerous sites in psftp.c which called sftp_find_request have all been rewritten to do this instead, and as a side effect they now look more sensible. The only other uses of sftp_find_request were in xfer_*load_gotpkt, which had to be tweaked in its own way. While I'm here, also fix memory management in sftp_find_request, which was freeing its input packet on some but not all error return paths. [originally from svn r9894]
2013-07-06 20:43:21 +00:00
req = fxp_close_send(fh);
pktin = sftp_wait_for_reply(req);
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
fxp_close_recv(pktin, req);
First phase of SFTP re-engineering. Each base-level fxp_* function has been split into a send half and a receive half, so that callers can set several requests in motion at a time and deal with the responses in whatever order they arrive. [originally from svn r3318]
2003-06-29 14:26:09 +00:00
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
return false;
First stab at an SFTP client. Currently a Unixland testing app, not integrated into PuTTY. [originally from svn r938]
2001-02-23 18:21:44 +00:00
}
More upgrades to psftp: it now supports mv, chmod, reget and reput. [originally from svn r1203]
2001-08-26 11:35:11 +00:00
if (restart) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
if (seek_file(file, 0, FROM_END) == -1) {
close_wfile(file);
File transfer tools: sanitise remote filenames and stderr. This commit adds sanitisation to PSCP and PSFTP in the same style as I've just put it into Plink. This time, standard error is sanitised without reference to whether it's redirected (at least unless you give an override option), on the basis that where Plink is _sometimes_ an SSH transport for some other protocol, PSCP and PSFTP _always_ are. But also, the sanitiser is run over any remote filename sent by the server, substituting ? for any control characters it finds. That removes another avenue for the server to deliberately confuse the display. This commit fixes our bug 'pscp-unsanitised-server-output', aka the two notional 'vulnerabilities' CVE-2019-6109 and CVE-2019-6110. (Although we regard those in isolation as only bugs, not serious vulnerabilities, because their main threat was in hiding the evidence of a server having exploited other more serious vulns that we never had.)
2019-02-20 07:09:10 +00:00
with_stripctrl(san, outfname)
printf("reget: cannot restart %s - file too large\n", san);
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
req = fxp_close_send(fh);
Clean up handling of the return value from sftp_find_request. In many places we simply enforce by assertion that it will match the request we sent out a moment ago: in fact it can also return NULL, so it makes more sense to report a proper error message if it doesn't return the expected value, and while we're at it, have that error message whatever message was helpfully left in fxp_error() by sftp_find_request when it failed. To do this, I've written a centralised function in psftp.c called sftp_wait_for_reply, which is handed a request that's just been sent out and deals with the mechanics of waiting for its reply, returning the reply when it arrives, and aborting with a sensible error if anything else arrives instead. The numerous sites in psftp.c which called sftp_find_request have all been rewritten to do this instead, and as a side effect they now look more sensible. The only other uses of sftp_find_request were in xfer_*load_gotpkt, which had to be tweaked in its own way. While I'm here, also fix memory management in sftp_find_request, which was freeing its input packet on some but not all error return paths. [originally from svn r9894]
2013-07-06 20:43:21 +00:00
pktin = sftp_wait_for_reply(req);
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
fxp_close_recv(pktin, req);
return false;
}
offset = get_file_posn(file);
printf("reget: restarting at file position %"PRIu64"\n", offset);
More upgrades to psftp: it now supports mv, chmod, reget and reput. [originally from svn r1203]
2001-08-26 11:35:11 +00:00
} else {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
offset = 0;
More upgrades to psftp: it now supports mv, chmod, reget and reput. [originally from svn r1203]
2001-08-26 11:35:11 +00:00
}
First stab at an SFTP client. Currently a Unixland testing app, not integrated into PuTTY. [originally from svn r938]
2001-02-23 18:21:44 +00:00
File transfer tools: sanitise remote filenames and stderr. This commit adds sanitisation to PSCP and PSFTP in the same style as I've just put it into Plink. This time, standard error is sanitised without reference to whether it's redirected (at least unless you give an override option), on the basis that where Plink is _sometimes_ an SSH transport for some other protocol, PSCP and PSFTP _always_ are. But also, the sanitiser is run over any remote filename sent by the server, substituting ? for any control characters it finds. That removes another avenue for the server to deliberately confuse the display. This commit fixes our bug 'pscp-unsanitised-server-output', aka the two notional 'vulnerabilities' CVE-2019-6109 and CVE-2019-6110. (Although we regard those in isolation as only bugs, not serious vulnerabilities, because their main threat was in hiding the evidence of a server having exploited other more serious vulns that we never had.)
2019-02-20 07:09:10 +00:00
with_stripctrl(san, fname) {
with_stripctrl(sano, outfname)
printf("remote:%s => local:%s\n", san, sano);
}
First stab at an SFTP client. Currently a Unixland testing app, not integrated into PuTTY. [originally from svn r938]
2001-02-23 18:21:44 +00:00
/*
* FIXME: we can use FXP_FSTAT here to get the file size, and
* thus put up a progress bar.
*/
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
toret = true;
First cut at speeding up SFTP. Generic download-management code in sftp.c, and psftp.c now uses that instead of going it alone. Should in principle be easily installed in PSCP as well, but I haven't done it yet; also it only handles downloads, not uploads, and finally it doesn't yet properly calculate the correct number of parallel requests to queue. Still, it's a start, and in my own tests it seemed to perform as expected (download speed suddenly became roughly what you'd expect from the available bandwidth, and decreased by roughly the expected number of round-trip times). [originally from svn r3468]
2003-09-27 17:52:34 +00:00
xfer = xfer_download_init(fh, offset);
Uploads turn out to be much easier than downloads, so here's faster upload support in PSFTP as well. [originally from svn r3470]
2003-09-28 14:24:01 +00:00
while (!xfer_done(xfer)) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
void *vbuf;
int retd, len;
int wpos, wlen;
xfer_download_queue(xfer);
pktin = sftp_recv();
retd = xfer_download_gotpkt(xfer, pktin);
if (retd <= 0) {
if (!shown_err) {
printf("error while reading: %s\n", fxp_error());
shown_err = true;
}
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
if (retd == INT_MIN) /* pktin not even freed */
xfer_{up,down}load_gotpkt free their input sftp_packet as a side effect of handling it, but they do not free it if it isn't a packet they recognise as part of their upload/download. Invent a return value that specifically signals this, and consistently free pktin at every call site if that return value comes back. Also, ensure that that return value also always comes with something meaningful in fxp_error. [originally from svn r9915]
2013-07-11 17:24:53 +00:00
sfree(pktin);
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
toret = false;
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
}
while (xfer_download_data(xfer, &vbuf, &len)) {
unsigned char *buf = (unsigned char *)vbuf;
wpos = 0;
while (wpos < len) {
wlen = write_to_file(file, buf + wpos, len - wpos);
if (wlen <= 0) {
printf("error while writing local file\n");
toret = false;
xfer_set_error(xfer);
break;
}
wpos += wlen;
}
if (wpos < len) { /* we had an error */
toret = false;
xfer_set_error(xfer);
}
sfree(vbuf);
}
First stab at an SFTP client. Currently a Unixland testing app, not integrated into PuTTY. [originally from svn r938]
2001-02-23 18:21:44 +00:00
}
First cut at speeding up SFTP. Generic download-management code in sftp.c, and psftp.c now uses that instead of going it alone. Should in principle be easily installed in PSCP as well, but I haven't done it yet; also it only handles downloads, not uploads, and finally it doesn't yet properly calculate the correct number of parallel requests to queue. Still, it's a start, and in my own tests it seemed to perform as expected (download speed suddenly became roughly what you'd expect from the available bandwidth, and decreased by roughly the expected number of round-trip times). [originally from svn r3468]
2003-09-27 17:52:34 +00:00
xfer_cleanup(xfer);
Large file support for psftp and pscp on both Windows and Unix. On Unix we set _FILE_OFFSET_BITS to 64 on the compiler command line (via mkfiles.pl), and on Windows we use SetFilePointer and GetFileSize to cope with 64-bit sizes where possible. Not tested on Win9x. [originally from svn r6783]
2006-08-12 15:20:19 +00:00
close_wfile(file);
First phase of SFTP re-engineering. Each base-level fxp_* function has been split into a send half and a receive half, so that callers can set several requests in motion at a time and deal with the responses in whatever order they arrive. [originally from svn r3318]
2003-06-29 14:26:09 +00:00
Clean up handling of the return value from sftp_find_request. In many places we simply enforce by assertion that it will match the request we sent out a moment ago: in fact it can also return NULL, so it makes more sense to report a proper error message if it doesn't return the expected value, and while we're at it, have that error message whatever message was helpfully left in fxp_error() by sftp_find_request when it failed. To do this, I've written a centralised function in psftp.c called sftp_wait_for_reply, which is handed a request that's just been sent out and deals with the mechanics of waiting for its reply, returning the reply when it arrives, and aborting with a sensible error if anything else arrives instead. The numerous sites in psftp.c which called sftp_find_request have all been rewritten to do this instead, and as a side effect they now look more sensible. The only other uses of sftp_find_request were in xfer_*load_gotpkt, which had to be tweaked in its own way. While I'm here, also fix memory management in sftp_find_request, which was freeing its input packet on some but not all error return paths. [originally from svn r9894]
2013-07-06 20:43:21 +00:00
req = fxp_close_send(fh);
pktin = sftp_wait_for_reply(req);
fxp_close_recv(pktin, req);
First phase of SFTP re-engineering. Each base-level fxp_* function has been split into a send half and a receive half, so that callers can set several requests in motion at a time and deal with the responses in whatever order they arrive. [originally from svn r3318]
2003-06-29 14:26:09 +00:00
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
return toret;
First stab at an SFTP client. Currently a Unixland testing app, not integrated into PuTTY. [originally from svn r938]
2001-02-23 18:21:44 +00:00
}
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
bool sftp_put_file(char *fname, char *outfname, bool recurse, bool restart)
Run entire source base through GNU indent to tidy up the varying coding styles of the various contributors! Woohoo! [originally from svn r1098]
2001-05-06 14:35:20 +00:00
{
First stab at an SFTP client. Currently a Unixland testing app, not integrated into PuTTY. [originally from svn r938]
2001-02-23 18:21:44 +00:00
struct fxp_handle *fh;
Uploads turn out to be much easier than downloads, so here's faster upload support in PSFTP as well. [originally from svn r3470]
2003-09-28 14:24:01 +00:00
struct fxp_xfer *xfer;
First phase of SFTP re-engineering. Each base-level fxp_* function has been split into a send half and a receive half, so that callers can set several requests in motion at a time and deal with the responses in whatever order they arrive. [originally from svn r3318]
2003-06-29 14:26:09 +00:00
struct sftp_packet *pktin;
Clean up handling of the return value from sftp_find_request. In many places we simply enforce by assertion that it will match the request we sent out a moment ago: in fact it can also return NULL, so it makes more sense to report a proper error message if it doesn't return the expected value, and while we're at it, have that error message whatever message was helpfully left in fxp_error() by sftp_find_request when it failed. To do this, I've written a centralised function in psftp.c called sftp_wait_for_reply, which is handed a request that's just been sent out and deals with the mechanics of waiting for its reply, returning the reply when it arrives, and aborting with a sensible error if anything else arrives instead. The numerous sites in psftp.c which called sftp_find_request have all been rewritten to do this instead, and as a side effect they now look more sensible. The only other uses of sftp_find_request were in xfer_*load_gotpkt, which had to be tweaked in its own way. While I'm here, also fix memory management in sftp_find_request, which was freeing its input packet on some but not all error return paths. [originally from svn r9894]
2013-07-06 20:43:21 +00:00
struct sftp_request *req;
Adopt C99 <stdint.h> integer types. The annoying int64.h is completely retired, since C99 guarantees a 64-bit integer type that you can actually treat like an ordinary integer. Also, I've replaced the local typedefs uint32 and word32 (scattered through different parts of the crypto code) with the standard uint32_t.
2018-10-26 22:08:58 +00:00
uint64_t offset;
Large file support for psftp and pscp on both Windows and Unix. On Unix we set _FILE_OFFSET_BITS to 64 on the compiler command line (via mkfiles.pl), and on Windows we use SetFilePointer and GetFileSize to cope with 64-bit sizes where possible. Not tested on Win9x. [originally from svn r6783]
2006-08-12 15:20:19 +00:00
RFile *file;
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
bool err = false, eof;
Propagate file permissions in both directions in Unix pscp and psftp. I think I have to consider this to be a separate but related change to the wishlist item 'pscp-filemodes'; that was written before the Unix port existed, and referred to the ability to configure the permissions used for files copied from Windows to Unix - which is still not done. [originally from svn r9260]
2011-08-11 17:59:30 +00:00
struct fxp_attrs attrs;
long permissions;
First stab at an SFTP client. Currently a Unixland testing app, not integrated into PuTTY. [originally from svn r938]
2001-02-23 18:21:44 +00:00
Support for recursive file transfer in PSFTP. [originally from svn r4990] [this svn revision also touched putty-wishlist]
2004-12-16 16:37:37 +00:00
/*
* In recursive mode, see if we're dealing with a directory.
* (If we're not in recursive mode, we need not even check: the
* subsequent fopen will return an error message.)
*/
I've decided that trying to do wildcards in PSFTP as a special case of directory recursion was a strategic error: it obfuscates sftp_{get,put}_file(), and also it makes it very hard to handle subdirectory wildcards such as `foo/*'. Accordingly, here's a completely different approach, in which sftp_{get,put}_file() are still responsible for directory recursion, but wildcards are expanded in sftp_general_{get,put}() before being passed thereto. Subdirectory wildcards are now handled consistently across Unix, Windows and the remote server. [originally from svn r5045]
2004-12-30 13:51:37 +00:00
if (recurse && file_type(fname) == FILE_TYPE_DIRECTORY) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
bool result;
size_t nnames, namesize;
char *name, **ournames;
pscp: replace crash with diagnostic on opendir failure. A user points out that the call to close_directory() in pscp.c's rsource() function should have been inside rather than outside the if statement that checks whether the directory handle is NULL. As a result, any failed attempt to open a directory during a 'pscp -r' recursive upload leads to a null-pointer dereference. Moved the close_directory call to where it should be, and also arranged to print the OS error code if the directory-open fails, by also changing the API of open_directory to return an error string on failure.
2018-12-27 16:52:23 +00:00
const char *opendir_err;
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
DirHandle *dh;
New array-growing macros: sgrowarray and sgrowarrayn. The idea of these is that they centralise the common idiom along the lines of if (logical_array_len >= physical_array_size) { physical_array_size = logical_array_len * 5 / 4 + 256; array = sresize(array, physical_array_size, ElementType); } which happens at a zillion call sites throughout this code base, with different random choices of the geometric factor and additive constant, sometimes forgetting them completely, and generally doing a lot of repeated work. The new macro sgrowarray(array,size,n) has the semantics: here are the array pointer and its physical size for you to modify, now please ensure that the nth element exists, so I can write into it. And sgrowarrayn(array,size,n,m) is the same except that it ensures that the array has size at least n+m (so sgrowarray is just the special case where m=1). Now that this is a single centralised implementation that will be used everywhere, I've also gone to more effort in the implementation, with careful overflow checks that would have been painful to put at all the previous call sites. This commit also switches over every use of sresize(), apart from a few where I really didn't think it would gain anything. A consequence of that is that a lot of array-size variables have to have their types changed to size_t, because the macros require that (they address-take the size to pass to the underlying function).
2019-02-28 20:07:30 +00:00
size_t i;
First stab at an SFTP client. Currently a Unixland testing app, not integrated into PuTTY. [originally from svn r938]
2001-02-23 18:21:44 +00:00
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
/*
* First, attempt to create the destination directory,
* unless it already exists.
*/
req = fxp_stat_send(outfname);
Clean up handling of the return value from sftp_find_request. In many places we simply enforce by assertion that it will match the request we sent out a moment ago: in fact it can also return NULL, so it makes more sense to report a proper error message if it doesn't return the expected value, and while we're at it, have that error message whatever message was helpfully left in fxp_error() by sftp_find_request when it failed. To do this, I've written a centralised function in psftp.c called sftp_wait_for_reply, which is handed a request that's just been sent out and deals with the mechanics of waiting for its reply, returning the reply when it arrives, and aborting with a sensible error if anything else arrives instead. The numerous sites in psftp.c which called sftp_find_request have all been rewritten to do this instead, and as a side effect they now look more sensible. The only other uses of sftp_find_request were in xfer_*load_gotpkt, which had to be tweaked in its own way. While I'm here, also fix memory management in sftp_find_request, which was freeing its input packet on some but not all error return paths. [originally from svn r9894]
2013-07-06 20:43:21 +00:00
pktin = sftp_wait_for_reply(req);
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
result = fxp_stat_recv(pktin, req, &attrs);
if (!result ||
!(attrs.flags & SSH_FILEXFER_ATTR_PERMISSIONS) ||
!(attrs.permissions & 0040000)) {
req = fxp_mkdir_send(outfname, NULL);
Clean up handling of the return value from sftp_find_request. In many places we simply enforce by assertion that it will match the request we sent out a moment ago: in fact it can also return NULL, so it makes more sense to report a proper error message if it doesn't return the expected value, and while we're at it, have that error message whatever message was helpfully left in fxp_error() by sftp_find_request when it failed. To do this, I've written a centralised function in psftp.c called sftp_wait_for_reply, which is handed a request that's just been sent out and deals with the mechanics of waiting for its reply, returning the reply when it arrives, and aborting with a sensible error if anything else arrives instead. The numerous sites in psftp.c which called sftp_find_request have all been rewritten to do this instead, and as a side effect they now look more sensible. The only other uses of sftp_find_request were in xfer_*load_gotpkt, which had to be tweaked in its own way. While I'm here, also fix memory management in sftp_find_request, which was freeing its input packet on some but not all error return paths. [originally from svn r9894]
2013-07-06 20:43:21 +00:00
pktin = sftp_wait_for_reply(req);
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
result = fxp_mkdir_recv(pktin, req);
if (!result) {
printf("%s: create directory: %s\n",
outfname, fxp_error());
return false;
}
}
/*
* Now get the list of filenames in the local directory.
*/
nnames = namesize = 0;
ournames = NULL;
dh = open_directory(fname, &opendir_err);
if (!dh) {
printf("%s: unable to open directory: %s\n", fname, opendir_err);
return false;
}
while ((name = read_filename(dh)) != NULL) {
New array-growing macros: sgrowarray and sgrowarrayn. The idea of these is that they centralise the common idiom along the lines of if (logical_array_len >= physical_array_size) { physical_array_size = logical_array_len * 5 / 4 + 256; array = sresize(array, physical_array_size, ElementType); } which happens at a zillion call sites throughout this code base, with different random choices of the geometric factor and additive constant, sometimes forgetting them completely, and generally doing a lot of repeated work. The new macro sgrowarray(array,size,n) has the semantics: here are the array pointer and its physical size for you to modify, now please ensure that the nth element exists, so I can write into it. And sgrowarrayn(array,size,n,m) is the same except that it ensures that the array has size at least n+m (so sgrowarray is just the special case where m=1). Now that this is a single centralised implementation that will be used everywhere, I've also gone to more effort in the implementation, with careful overflow checks that would have been painful to put at all the previous call sites. This commit also switches over every use of sresize(), apart from a few where I really didn't think it would gain anything. A consequence of that is that a lot of array-size variables have to have their types changed to size_t, because the macros require that (they address-take the size to pass to the underlying function).
2019-02-28 20:07:30 +00:00
sgrowarray(ournames, namesize, nnames);
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
ournames[nnames++] = name;
}
close_directory(dh);
/*
* Sort the names into a clear order. This ought to make
* things more predictable when we're doing a reput of the
* same directory, just in case two readdirs on the same
* local directory return a different order.
*/
It's not actually legal by the C standard to call qsort with a null array pointer, _even_ if you're asking it to sort zero elements so that in principle it should never dereference that pointer. Fix the four instances in PSCP/PSFTP where this was previously occurring. [originally from svn r9912]
2013-07-11 17:24:39 +00:00
if (nnames > 0)
qsort(ournames, nnames, sizeof(*ournames), bare_name_compare);
Support for recursive file transfer in PSFTP. [originally from svn r4990] [this svn revision also touched putty-wishlist]
2004-12-16 16:37:37 +00:00
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
/*
* If we're in restart mode, find the last filename on this
* list that already exists. We may have to do a reput on
* _that_ file, but shouldn't have to do anything on the
* previous files.
*
* If none of them exists, of course, we start at 0.
*/
i = 0;
When the comments say `if we're in restart mode', the code in question should actually be conditional on restart mode! [originally from svn r7438]
2007-04-02 08:44:00 +00:00
if (restart) {
while (i < nnames) {
char *nextoutfname;
Make dupcat() into a variadic macro. Up until now, it's been a variadic _function_, whose argument list consists of 'const char *' ASCIZ strings to concatenate, terminated by one containing a null pointer. Now, that function is dupcat_fn(), and it's wrapped by a C99 variadic _macro_ called dupcat(), which automatically suffixes the null-pointer terminating argument. This has three benefits. Firstly, it's just less effort at every call site. Secondly, it protects against the risk of accidentally leaving off the NULL, causing arbitrary words of stack memory to be dereferenced as char pointers. And thirdly, it protects against the more subtle risk of writing a bare 'NULL' as the terminating argument, instead of casting it explicitly to a pointer. That last one is necessary because C permits the macro NULL to expand to an integer constant such as 0, so NULL by itself may not have pointer type, and worse, it may not be marshalled in a variadic argument list in the same way as a pointer. (For example, on a 64-bit machine it might only occupy 32 bits. And yet, on another 64-bit platform, it might work just fine, so that you don't notice the mistake!) I was inspired to do this by happening to notice one of those bare NULL terminators, and thinking I'd better check if there were any more. Turned out there were quite a few. Now there are none.
2019-10-14 18:42:37 +00:00
nextoutfname = dupcat(outfname, "/", ournames[i]);
Clean up handling of the return value from sftp_find_request. In many places we simply enforce by assertion that it will match the request we sent out a moment ago: in fact it can also return NULL, so it makes more sense to report a proper error message if it doesn't return the expected value, and while we're at it, have that error message whatever message was helpfully left in fxp_error() by sftp_find_request when it failed. To do this, I've written a centralised function in psftp.c called sftp_wait_for_reply, which is handed a request that's just been sent out and deals with the mechanics of waiting for its reply, returning the reply when it arrives, and aborting with a sensible error if anything else arrives instead. The numerous sites in psftp.c which called sftp_find_request have all been rewritten to do this instead, and as a side effect they now look more sensible. The only other uses of sftp_find_request were in xfer_*load_gotpkt, which had to be tweaked in its own way. While I'm here, also fix memory management in sftp_find_request, which was freeing its input packet on some but not all error return paths. [originally from svn r9894]
2013-07-06 20:43:21 +00:00
req = fxp_stat_send(nextoutfname);
pktin = sftp_wait_for_reply(req);
result = fxp_stat_recv(pktin, req, &attrs);
When the comments say `if we're in restart mode', the code in question should actually be conditional on restart mode! [originally from svn r7438]
2007-04-02 08:44:00 +00:00
sfree(nextoutfname);
if (!result)
break;
i++;
}
if (i > 0)
i--;
}
/*
* Now we're ready to recurse. Starting at ournames[i]
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
* and continuing on to the end of the list, we
* construct a new source and target file name, and
* call sftp_put_file again.
*/
for (; i < nnames; i++) {
char *nextfname, *nextoutfname;
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
bool retd;
Support for recursive file transfer in PSFTP. [originally from svn r4990] [this svn revision also touched putty-wishlist]
2004-12-16 16:37:37 +00:00
Remove redundant null checks for arguments to sftp_{get,put}_file which are (a) never NULL anyway, and (b) have already been dereferenced by the time we make those checks so it would be too late if they were. [originally from svn r9906]
2013-07-11 17:24:10 +00:00
nextfname = dir_file_cat(fname, ournames[i]);
Make dupcat() into a variadic macro. Up until now, it's been a variadic _function_, whose argument list consists of 'const char *' ASCIZ strings to concatenate, terminated by one containing a null pointer. Now, that function is dupcat_fn(), and it's wrapped by a C99 variadic _macro_ called dupcat(), which automatically suffixes the null-pointer terminating argument. This has three benefits. Firstly, it's just less effort at every call site. Secondly, it protects against the risk of accidentally leaving off the NULL, causing arbitrary words of stack memory to be dereferenced as char pointers. And thirdly, it protects against the more subtle risk of writing a bare 'NULL' as the terminating argument, instead of casting it explicitly to a pointer. That last one is necessary because C permits the macro NULL to expand to an integer constant such as 0, so NULL by itself may not have pointer type, and worse, it may not be marshalled in a variadic argument list in the same way as a pointer. (For example, on a 64-bit machine it might only occupy 32 bits. And yet, on another 64-bit platform, it might work just fine, so that you don't notice the mistake!) I was inspired to do this by happening to notice one of those bare NULL terminators, and thinking I'd better check if there were any more. Turned out there were quite a few. Now there are none.
2019-10-14 18:42:37 +00:00
nextoutfname = dupcat(outfname, "/", ournames[i]);
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
retd = sftp_put_file(nextfname, nextoutfname, recurse, restart);
restart = false; /* after first partial file, do full */
sfree(nextoutfname);
sfree(nextfname);
if (!retd) {
for (size_t i = 0; i < nnames; i++) {
sfree(ournames[i]);
}
sfree(ournames);
return false;
}
}
/*
* Done this recursion level. Free everything.
*/
for (size_t i = 0; i < nnames; i++) {
sfree(ournames[i]);
}
sfree(ournames);
return true;
First stab at an SFTP client. Currently a Unixland testing app, not integrated into PuTTY. [originally from svn r938]
2001-02-23 18:21:44 +00:00
}
Propagate file permissions in both directions in Unix pscp and psftp. I think I have to consider this to be a separate but related change to the wishlist item 'pscp-filemodes'; that was written before the Unix port existed, and referred to the ability to configure the permissions used for files copied from Windows to Unix - which is still not done. [originally from svn r9260]
2011-08-11 17:59:30 +00:00
file = open_existing_file(fname, NULL, NULL, NULL, &permissions);
Large file support for psftp and pscp on both Windows and Unix. On Unix we set _FILE_OFFSET_BITS to 64 on the compiler command line (via mkfiles.pl), and on Windows we use SetFilePointer and GetFileSize to cope with 64-bit sizes where possible. Not tested on Win9x. [originally from svn r6783]
2006-08-12 15:20:19 +00:00
if (!file) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
printf("local: unable to open %s\n", fname);
return false;
First stab at an SFTP client. Currently a Unixland testing app, not integrated into PuTTY. [originally from svn r938]
2001-02-23 18:21:44 +00:00
}
Propagate file permissions in both directions in Unix pscp and psftp. I think I have to consider this to be a separate but related change to the wishlist item 'pscp-filemodes'; that was written before the Unix port existed, and referred to the ability to configure the permissions used for files copied from Windows to Unix - which is still not done. [originally from svn r9260]
2011-08-11 17:59:30 +00:00
attrs.flags = 0;
PUT_PERMISSIONS(attrs, permissions);
More upgrades to psftp: it now supports mv, chmod, reget and reput. [originally from svn r1203]
2001-08-26 11:35:11 +00:00
if (restart) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
req = fxp_open_send(outfname, SSH_FXF_WRITE, &attrs);
More upgrades to psftp: it now supports mv, chmod, reget and reput. [originally from svn r1203]
2001-08-26 11:35:11 +00:00
} else {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
req = fxp_open_send(outfname,
Clean up handling of the return value from sftp_find_request. In many places we simply enforce by assertion that it will match the request we sent out a moment ago: in fact it can also return NULL, so it makes more sense to report a proper error message if it doesn't return the expected value, and while we're at it, have that error message whatever message was helpfully left in fxp_error() by sftp_find_request when it failed. To do this, I've written a centralised function in psftp.c called sftp_wait_for_reply, which is handed a request that's just been sent out and deals with the mechanics of waiting for its reply, returning the reply when it arrives, and aborting with a sensible error if anything else arrives instead. The numerous sites in psftp.c which called sftp_find_request have all been rewritten to do this instead, and as a side effect they now look more sensible. The only other uses of sftp_find_request were in xfer_*load_gotpkt, which had to be tweaked in its own way. While I'm here, also fix memory management in sftp_find_request, which was freeing its input packet on some but not all error return paths. [originally from svn r9894]
2013-07-06 20:43:21 +00:00
SSH_FXF_WRITE | SSH_FXF_CREAT | SSH_FXF_TRUNC,
&attrs);
More upgrades to psftp: it now supports mv, chmod, reget and reput. [originally from svn r1203]
2001-08-26 11:35:11 +00:00
}
Clean up handling of the return value from sftp_find_request. In many places we simply enforce by assertion that it will match the request we sent out a moment ago: in fact it can also return NULL, so it makes more sense to report a proper error message if it doesn't return the expected value, and while we're at it, have that error message whatever message was helpfully left in fxp_error() by sftp_find_request when it failed. To do this, I've written a centralised function in psftp.c called sftp_wait_for_reply, which is handed a request that's just been sent out and deals with the mechanics of waiting for its reply, returning the reply when it arrives, and aborting with a sensible error if anything else arrives instead. The numerous sites in psftp.c which called sftp_find_request have all been rewritten to do this instead, and as a side effect they now look more sensible. The only other uses of sftp_find_request were in xfer_*load_gotpkt, which had to be tweaked in its own way. While I'm here, also fix memory management in sftp_find_request, which was freeing its input packet on some but not all error return paths. [originally from svn r9894]
2013-07-06 20:43:21 +00:00
pktin = sftp_wait_for_reply(req);
fh = fxp_open_recv(pktin, req);
First phase of SFTP re-engineering. Each base-level fxp_* function has been split into a send half and a receive half, so that callers can set several requests in motion at a time and deal with the responses in whatever order they arrive. [originally from svn r3318]
2003-06-29 14:26:09 +00:00
First stab at an SFTP client. Currently a Unixland testing app, not integrated into PuTTY. [originally from svn r938]
2001-02-23 18:21:44 +00:00
if (!fh) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
close_rfile(file);
printf("%s: open for write: %s\n", outfname, fxp_error());
return false;
First stab at an SFTP client. Currently a Unixland testing app, not integrated into PuTTY. [originally from svn r938]
2001-02-23 18:21:44 +00:00
}
More upgrades to psftp: it now supports mv, chmod, reget and reput. [originally from svn r1203]
2001-08-26 11:35:11 +00:00
if (restart) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
struct fxp_attrs attrs;
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
bool retd;
First phase of SFTP re-engineering. Each base-level fxp_* function has been split into a send half and a receive half, so that callers can set several requests in motion at a time and deal with the responses in whatever order they arrive. [originally from svn r3318]
2003-06-29 14:26:09 +00:00
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
req = fxp_fstat_send(fh);
Clean up handling of the return value from sftp_find_request. In many places we simply enforce by assertion that it will match the request we sent out a moment ago: in fact it can also return NULL, so it makes more sense to report a proper error message if it doesn't return the expected value, and while we're at it, have that error message whatever message was helpfully left in fxp_error() by sftp_find_request when it failed. To do this, I've written a centralised function in psftp.c called sftp_wait_for_reply, which is handed a request that's just been sent out and deals with the mechanics of waiting for its reply, returning the reply when it arrives, and aborting with a sensible error if anything else arrives instead. The numerous sites in psftp.c which called sftp_find_request have all been rewritten to do this instead, and as a side effect they now look more sensible. The only other uses of sftp_find_request were in xfer_*load_gotpkt, which had to be tweaked in its own way. While I'm here, also fix memory management in sftp_find_request, which was freeing its input packet on some but not all error return paths. [originally from svn r9894]
2013-07-06 20:43:21 +00:00
pktin = sftp_wait_for_reply(req);
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
retd = fxp_fstat_recv(pktin, req, &attrs);
First phase of SFTP re-engineering. Each base-level fxp_* function has been split into a send half and a receive half, so that callers can set several requests in motion at a time and deal with the responses in whatever order they arrive. [originally from svn r3318]
2003-06-29 14:26:09 +00:00
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
if (!retd) {
printf("read size of %s: %s\n", outfname, fxp_error());
err = true;
Close the remote file handle if sftp_put_file's fstat fails. Instead of abruptly returning from sftp_put_file in that situation, we now send an FXP_CLOSE instead. Patch due to Tim Kosse.
2014-12-20 16:53:01 +00:00
goto cleanup;
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
}
if (!(attrs.flags & SSH_FILEXFER_ATTR_SIZE)) {
printf("read size of %s: size was not given\n", outfname);
err = true;
Close the remote file handle if sftp_put_file's fstat fails. Instead of abruptly returning from sftp_put_file in that situation, we now send an FXP_CLOSE instead. Patch due to Tim Kosse.
2014-12-20 16:53:01 +00:00
goto cleanup;
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
}
offset = attrs.size;
printf("reput: restarting at file position %"PRIu64"\n", offset);
Large file support for psftp and pscp on both Windows and Unix. On Unix we set _FILE_OFFSET_BITS to 64 on the compiler command line (via mkfiles.pl), and on Windows we use SetFilePointer and GetFileSize to cope with 64-bit sizes where possible. Not tested on Win9x. [originally from svn r6783]
2006-08-12 15:20:19 +00:00
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
if (seek_file((WFile *)file, offset, FROM_START) != 0)
seek_file((WFile *)file, 0, FROM_END); /* *shrug* */
More upgrades to psftp: it now supports mv, chmod, reget and reput. [originally from svn r1203]
2001-08-26 11:35:11 +00:00
} else {
Adopt C99 <stdint.h> integer types. The annoying int64.h is completely retired, since C99 guarantees a 64-bit integer type that you can actually treat like an ordinary integer. Also, I've replaced the local typedefs uint32 and word32 (scattered through different parts of the crypto code) with the standard uint32_t.
2018-10-26 22:08:58 +00:00
offset = 0;
More upgrades to psftp: it now supports mv, chmod, reget and reput. [originally from svn r1203]
2001-08-26 11:35:11 +00:00
}
First stab at an SFTP client. Currently a Unixland testing app, not integrated into PuTTY. [originally from svn r938]
2001-02-23 18:21:44 +00:00
More upgrades to psftp: it now supports mv, chmod, reget and reput. [originally from svn r1203]
2001-08-26 11:35:11 +00:00
printf("local:%s => remote:%s\n", fname, outfname);
First stab at an SFTP client. Currently a Unixland testing app, not integrated into PuTTY. [originally from svn r938]
2001-02-23 18:21:44 +00:00
/*
* FIXME: we can use FXP_FSTAT here to get the file size, and
* thus put up a progress bar.
*/
Uploads turn out to be much easier than downloads, so here's faster upload support in PSFTP as well. [originally from svn r3470]
2003-09-28 14:24:01 +00:00
xfer = xfer_upload_init(fh, offset);
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
eof = false;
Uploads turn out to be much easier than downloads, so here's faster upload support in PSFTP as well. [originally from svn r3470]
2003-09-28 14:24:01 +00:00
while ((!err && !eof) || !xfer_done(xfer)) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
char buffer[4096];
int len, ret;
while (xfer_upload_ready(xfer) && !err && !eof) {
len = read_from_file(file, buffer, sizeof(buffer));
if (len == -1) {
printf("error while reading local file\n");
err = true;
} else if (len == 0) {
eof = true;
} else {
xfer_upload_data(xfer, buffer, len);
}
}
if (!xfer_done(xfer)) {
pktin = sftp_recv();
ret = xfer_upload_gotpkt(xfer, pktin);
if (ret <= 0) {
xfer_{up,down}load_gotpkt free their input sftp_packet as a side effect of handling it, but they do not free it if it isn't a packet they recognise as part of their upload/download. Invent a return value that specifically signals this, and consistently free pktin at every call site if that return value comes back. Also, ensure that that return value also always comes with something meaningful in fxp_error. [originally from svn r9915]
2013-07-11 17:24:53 +00:00
if (ret == INT_MIN) /* pktin not even freed */
sfree(pktin);
if (!err) {
printf("error while writing: %s\n", fxp_error());
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
err = true;
xfer_{up,down}load_gotpkt free their input sftp_packet as a side effect of handling it, but they do not free it if it isn't a packet they recognise as part of their upload/download. Invent a return value that specifically signals this, and consistently free pktin at every call site if that return value comes back. Also, ensure that that return value also always comes with something meaningful in fxp_error. [originally from svn r9915]
2013-07-11 17:24:53 +00:00
}
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
}
}
First stab at an SFTP client. Currently a Unixland testing app, not integrated into PuTTY. [originally from svn r938]
2001-02-23 18:21:44 +00:00
}
Uploads turn out to be much easier than downloads, so here's faster upload support in PSFTP as well. [originally from svn r3470]
2003-09-28 14:24:01 +00:00
xfer_cleanup(xfer);
Close the remote file handle if sftp_put_file's fstat fails. Instead of abruptly returning from sftp_put_file in that situation, we now send an FXP_CLOSE instead. Patch due to Tim Kosse.
2014-12-20 16:53:01 +00:00
cleanup:
Clean up handling of the return value from sftp_find_request. In many places we simply enforce by assertion that it will match the request we sent out a moment ago: in fact it can also return NULL, so it makes more sense to report a proper error message if it doesn't return the expected value, and while we're at it, have that error message whatever message was helpfully left in fxp_error() by sftp_find_request when it failed. To do this, I've written a centralised function in psftp.c called sftp_wait_for_reply, which is handed a request that's just been sent out and deals with the mechanics of waiting for its reply, returning the reply when it arrives, and aborting with a sensible error if anything else arrives instead. The numerous sites in psftp.c which called sftp_find_request have all been rewritten to do this instead, and as a side effect they now look more sensible. The only other uses of sftp_find_request were in xfer_*load_gotpkt, which had to be tweaked in its own way. While I'm here, also fix memory management in sftp_find_request, which was freeing its input packet on some but not all error return paths. [originally from svn r9894]
2013-07-06 20:43:21 +00:00
req = fxp_close_send(fh);
pktin = sftp_wait_for_reply(req);
Remove/rescope variable 'ret' in sftp_put_file. This is a purely stylistic cleanup - no functional change intended - after Tim Kosse's changes in commits e9a76883a and 6f871e3d2. I think the underlying cause of the confusion whose functional effects he was fixing there is that I have the bad habit of tending to call variables 'ret' for two different reasons: one is because it's holding the value returned from some subroutine I've just called, and the other is because it's holding the value I'm preparing to return from the routine _containing_ the variable. The reason it's a bad habit is that I confuse the two purposes, and a variable of one type ends up accidentally being treated as the other. So while Tim's commits have already fixed the functional effects of the error in this case, this change should help prevent a recurrence because now there's no variable called 'ret' at all that's in scope for the whole function.
2016-12-29 11:25:34 +00:00
if (!fxp_close_recv(pktin, req)) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
if (!err) {
printf("error while closing: %s", fxp_error());
err = true;
}
Handle failed SSH_FXP_CLOSE requests in sftp_put_file. It is possible for SSH_FXP_CLOSE requests to fail. This can happen if the server buffers writes and an error occurs flushing the data to disk while processing the SSH_FXP_CLOSE request. If the close fails, sftp_put_file now returns an error as well.
2016-12-28 14:34:53 +00:00
}
First phase of SFTP re-engineering. Each base-level fxp_* function has been split into a send half and a receive half, so that callers can set several requests in motion at a time and deal with the responses in whatever order they arrive. [originally from svn r3318]
2003-06-29 14:26:09 +00:00
Large file support for psftp and pscp on both Windows and Unix. On Unix we set _FILE_OFFSET_BITS to 64 on the compiler command line (via mkfiles.pl), and on Windows we use SetFilePointer and GetFileSize to cope with 64-bit sizes where possible. Not tested on Win9x. [originally from svn r6783]
2006-08-12 15:20:19 +00:00
close_rfile(file);
Support for recursive file transfer in PSFTP. [originally from svn r4990] [this svn revision also touched putty-wishlist]
2004-12-16 16:37:37 +00:00
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
return !err;
Support for recursive file transfer in PSFTP. [originally from svn r4990] [this svn revision also touched putty-wishlist]
2004-12-16 16:37:37 +00:00
}
I've decided that trying to do wildcards in PSFTP as a special case of directory recursion was a strategic error: it obfuscates sftp_{get,put}_file(), and also it makes it very hard to handle subdirectory wildcards such as `foo/*'. Accordingly, here's a completely different approach, in which sftp_{get,put}_file() are still responsible for directory recursion, but wildcards are expanded in sftp_general_{get,put}() before being passed thereto. Subdirectory wildcards are now handled consistently across Unix, Windows and the remote server. [originally from svn r5045]
2004-12-30 13:51:37 +00:00
/* ----------------------------------------------------------------------
* A remote wildcard matcher, providing a similar interface to the
* local one in psftp.h.
*/
typedef struct SftpWildcardMatcher {
struct fxp_handle *dirh;
struct fxp_names *names;
int namepos;
char *wildcard, *prefix;
} SftpWildcardMatcher;
SftpWildcardMatcher *sftp_begin_wildcard_matching(char *name)
{
struct sftp_packet *pktin;
Clean up handling of the return value from sftp_find_request. In many places we simply enforce by assertion that it will match the request we sent out a moment ago: in fact it can also return NULL, so it makes more sense to report a proper error message if it doesn't return the expected value, and while we're at it, have that error message whatever message was helpfully left in fxp_error() by sftp_find_request when it failed. To do this, I've written a centralised function in psftp.c called sftp_wait_for_reply, which is handed a request that's just been sent out and deals with the mechanics of waiting for its reply, returning the reply when it arrives, and aborting with a sensible error if anything else arrives instead. The numerous sites in psftp.c which called sftp_find_request have all been rewritten to do this instead, and as a side effect they now look more sensible. The only other uses of sftp_find_request were in xfer_*load_gotpkt, which had to be tweaked in its own way. While I'm here, also fix memory management in sftp_find_request, which was freeing its input packet on some but not all error return paths. [originally from svn r9894]
2013-07-06 20:43:21 +00:00
struct sftp_request *req;
I've decided that trying to do wildcards in PSFTP as a special case of directory recursion was a strategic error: it obfuscates sftp_{get,put}_file(), and also it makes it very hard to handle subdirectory wildcards such as `foo/*'. Accordingly, here's a completely different approach, in which sftp_{get,put}_file() are still responsible for directory recursion, but wildcards are expanded in sftp_general_{get,put}() before being passed thereto. Subdirectory wildcards are now handled consistently across Unix, Windows and the remote server. [originally from svn r5045]
2004-12-30 13:51:37 +00:00
char *wildcard;
char *unwcdir, *tmpdir, *cdir;
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
int len;
bool check;
I've decided that trying to do wildcards in PSFTP as a special case of directory recursion was a strategic error: it obfuscates sftp_{get,put}_file(), and also it makes it very hard to handle subdirectory wildcards such as `foo/*'. Accordingly, here's a completely different approach, in which sftp_{get,put}_file() are still responsible for directory recursion, but wildcards are expanded in sftp_general_{get,put}() before being passed thereto. Subdirectory wildcards are now handled consistently across Unix, Windows and the remote server. [originally from svn r5045]
2004-12-30 13:51:37 +00:00
SftpWildcardMatcher *swcm;
struct fxp_handle *dirh;
/*
* We don't handle multi-level wildcards; so we expect to find
* a fully specified directory part, followed by a wildcard
* after that.
*/
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
wildcard = stripslashes(name, false);
I've decided that trying to do wildcards in PSFTP as a special case of directory recursion was a strategic error: it obfuscates sftp_{get,put}_file(), and also it makes it very hard to handle subdirectory wildcards such as `foo/*'. Accordingly, here's a completely different approach, in which sftp_{get,put}_file() are still responsible for directory recursion, but wildcards are expanded in sftp_general_{get,put}() before being passed thereto. Subdirectory wildcards are now handled consistently across Unix, Windows and the remote server. [originally from svn r5045]
2004-12-30 13:51:37 +00:00
unwcdir = dupstr(name);
len = wildcard - name;
unwcdir[len] = '\0';
if (len > 0 && unwcdir[len-1] == '/')
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
unwcdir[len-1] = '\0';
I've decided that trying to do wildcards in PSFTP as a special case of directory recursion was a strategic error: it obfuscates sftp_{get,put}_file(), and also it makes it very hard to handle subdirectory wildcards such as `foo/*'. Accordingly, here's a completely different approach, in which sftp_{get,put}_file() are still responsible for directory recursion, but wildcards are expanded in sftp_general_{get,put}() before being passed thereto. Subdirectory wildcards are now handled consistently across Unix, Windows and the remote server. [originally from svn r5045]
2004-12-30 13:51:37 +00:00
tmpdir = snewn(1 + len, char);
check = wc_unescape(tmpdir, unwcdir);
sfree(tmpdir);
if (!check) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
printf("Multiple-level wildcards are not supported\n");
sfree(unwcdir);
return NULL;
I've decided that trying to do wildcards in PSFTP as a special case of directory recursion was a strategic error: it obfuscates sftp_{get,put}_file(), and also it makes it very hard to handle subdirectory wildcards such as `foo/*'. Accordingly, here's a completely different approach, in which sftp_{get,put}_file() are still responsible for directory recursion, but wildcards are expanded in sftp_general_{get,put}() before being passed thereto. Subdirectory wildcards are now handled consistently across Unix, Windows and the remote server. [originally from svn r5045]
2004-12-30 13:51:37 +00:00
}
cdir = canonify(unwcdir);
Clean up handling of the return value from sftp_find_request. In many places we simply enforce by assertion that it will match the request we sent out a moment ago: in fact it can also return NULL, so it makes more sense to report a proper error message if it doesn't return the expected value, and while we're at it, have that error message whatever message was helpfully left in fxp_error() by sftp_find_request when it failed. To do this, I've written a centralised function in psftp.c called sftp_wait_for_reply, which is handed a request that's just been sent out and deals with the mechanics of waiting for its reply, returning the reply when it arrives, and aborting with a sensible error if anything else arrives instead. The numerous sites in psftp.c which called sftp_find_request have all been rewritten to do this instead, and as a side effect they now look more sensible. The only other uses of sftp_find_request were in xfer_*load_gotpkt, which had to be tweaked in its own way. While I'm here, also fix memory management in sftp_find_request, which was freeing its input packet on some but not all error return paths. [originally from svn r9894]
2013-07-06 20:43:21 +00:00
req = fxp_opendir_send(cdir);
pktin = sftp_wait_for_reply(req);
dirh = fxp_opendir_recv(pktin, req);
I've decided that trying to do wildcards in PSFTP as a special case of directory recursion was a strategic error: it obfuscates sftp_{get,put}_file(), and also it makes it very hard to handle subdirectory wildcards such as `foo/*'. Accordingly, here's a completely different approach, in which sftp_{get,put}_file() are still responsible for directory recursion, but wildcards are expanded in sftp_general_{get,put}() before being passed thereto. Subdirectory wildcards are now handled consistently across Unix, Windows and the remote server. [originally from svn r5045]
2004-12-30 13:51:37 +00:00
if (dirh) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
swcm = snew(SftpWildcardMatcher);
swcm->dirh = dirh;
swcm->names = NULL;
swcm->wildcard = dupstr(wildcard);
swcm->prefix = unwcdir;
I've decided that trying to do wildcards in PSFTP as a special case of directory recursion was a strategic error: it obfuscates sftp_{get,put}_file(), and also it makes it very hard to handle subdirectory wildcards such as `foo/*'. Accordingly, here's a completely different approach, in which sftp_{get,put}_file() are still responsible for directory recursion, but wildcards are expanded in sftp_general_{get,put}() before being passed thereto. Subdirectory wildcards are now handled consistently across Unix, Windows and the remote server. [originally from svn r5045]
2004-12-30 13:51:37 +00:00
} else {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
printf("Unable to open %s: %s\n", cdir, fxp_error());
swcm = NULL;
sfree(unwcdir);
I've decided that trying to do wildcards in PSFTP as a special case of directory recursion was a strategic error: it obfuscates sftp_{get,put}_file(), and also it makes it very hard to handle subdirectory wildcards such as `foo/*'. Accordingly, here's a completely different approach, in which sftp_{get,put}_file() are still responsible for directory recursion, but wildcards are expanded in sftp_general_{get,put}() before being passed thereto. Subdirectory wildcards are now handled consistently across Unix, Windows and the remote server. [originally from svn r5045]
2004-12-30 13:51:37 +00:00
}
sfree(cdir);
return swcm;
}
char *sftp_wildcard_get_filename(SftpWildcardMatcher *swcm)
{
struct fxp_name *name;
struct sftp_packet *pktin;
Clean up handling of the return value from sftp_find_request. In many places we simply enforce by assertion that it will match the request we sent out a moment ago: in fact it can also return NULL, so it makes more sense to report a proper error message if it doesn't return the expected value, and while we're at it, have that error message whatever message was helpfully left in fxp_error() by sftp_find_request when it failed. To do this, I've written a centralised function in psftp.c called sftp_wait_for_reply, which is handed a request that's just been sent out and deals with the mechanics of waiting for its reply, returning the reply when it arrives, and aborting with a sensible error if anything else arrives instead. The numerous sites in psftp.c which called sftp_find_request have all been rewritten to do this instead, and as a side effect they now look more sensible. The only other uses of sftp_find_request were in xfer_*load_gotpkt, which had to be tweaked in its own way. While I'm here, also fix memory management in sftp_find_request, which was freeing its input packet on some but not all error return paths. [originally from svn r9894]
2013-07-06 20:43:21 +00:00
struct sftp_request *req;
I've decided that trying to do wildcards in PSFTP as a special case of directory recursion was a strategic error: it obfuscates sftp_{get,put}_file(), and also it makes it very hard to handle subdirectory wildcards such as `foo/*'. Accordingly, here's a completely different approach, in which sftp_{get,put}_file() are still responsible for directory recursion, but wildcards are expanded in sftp_general_{get,put}() before being passed thereto. Subdirectory wildcards are now handled consistently across Unix, Windows and the remote server. [originally from svn r5045]
2004-12-30 13:51:37 +00:00
while (1) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
if (swcm->names && swcm->namepos >= swcm->names->nnames) {
fxp_free_names(swcm->names);
swcm->names = NULL;
}
I've decided that trying to do wildcards in PSFTP as a special case of directory recursion was a strategic error: it obfuscates sftp_{get,put}_file(), and also it makes it very hard to handle subdirectory wildcards such as `foo/*'. Accordingly, here's a completely different approach, in which sftp_{get,put}_file() are still responsible for directory recursion, but wildcards are expanded in sftp_general_{get,put}() before being passed thereto. Subdirectory wildcards are now handled consistently across Unix, Windows and the remote server. [originally from svn r5045]
2004-12-30 13:51:37 +00:00
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
if (!swcm->names) {
req = fxp_readdir_send(swcm->dirh);
Clean up handling of the return value from sftp_find_request. In many places we simply enforce by assertion that it will match the request we sent out a moment ago: in fact it can also return NULL, so it makes more sense to report a proper error message if it doesn't return the expected value, and while we're at it, have that error message whatever message was helpfully left in fxp_error() by sftp_find_request when it failed. To do this, I've written a centralised function in psftp.c called sftp_wait_for_reply, which is handed a request that's just been sent out and deals with the mechanics of waiting for its reply, returning the reply when it arrives, and aborting with a sensible error if anything else arrives instead. The numerous sites in psftp.c which called sftp_find_request have all been rewritten to do this instead, and as a side effect they now look more sensible. The only other uses of sftp_find_request were in xfer_*load_gotpkt, which had to be tweaked in its own way. While I'm here, also fix memory management in sftp_find_request, which was freeing its input packet on some but not all error return paths. [originally from svn r9894]
2013-07-06 20:43:21 +00:00
pktin = sftp_wait_for_reply(req);
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
swcm->names = fxp_readdir_recv(pktin, req);
I've decided that trying to do wildcards in PSFTP as a special case of directory recursion was a strategic error: it obfuscates sftp_{get,put}_file(), and also it makes it very hard to handle subdirectory wildcards such as `foo/*'. Accordingly, here's a completely different approach, in which sftp_{get,put}_file() are still responsible for directory recursion, but wildcards are expanded in sftp_general_{get,put}() before being passed thereto. Subdirectory wildcards are now handled consistently across Unix, Windows and the remote server. [originally from svn r5045]
2004-12-30 13:51:37 +00:00
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
if (!swcm->names) {
if (fxp_error_type() != SSH_FX_EOF) {
File transfer tools: sanitise remote filenames and stderr. This commit adds sanitisation to PSCP and PSFTP in the same style as I've just put it into Plink. This time, standard error is sanitised without reference to whether it's redirected (at least unless you give an override option), on the basis that where Plink is _sometimes_ an SSH transport for some other protocol, PSCP and PSFTP _always_ are. But also, the sanitiser is run over any remote filename sent by the server, substituting ? for any control characters it finds. That removes another avenue for the server to deliberately confuse the display. This commit fixes our bug 'pscp-unsanitised-server-output', aka the two notional 'vulnerabilities' CVE-2019-6109 and CVE-2019-6110. (Although we regard those in isolation as only bugs, not serious vulnerabilities, because their main threat was in hiding the evidence of a server having exploited other more serious vulns that we never had.)
2019-02-20 07:09:10 +00:00
with_stripctrl(san, swcm->prefix)
printf("%s: reading directory: %s\n",
san, fxp_error());
}
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
return NULL;
} else if (swcm->names->nnames == 0) {
John Hartnup reports that Apache SSHD's SFTP server responds to FXP_READDIR on an empty directory by returning a zero-length list of filenames, instead of the more common response of a list containing just "." and "..". Stop PSFTP failing an assertion when that happens. [originally from svn r9569]
2012-06-20 17:39:32 +00:00
/*
* Another failure mode which we treat as EOF is if
* the server reports success from FXP_READDIR but
* returns no actual names. This is unusual, since
* from most servers you'd expect at least "." and
* "..", but there's nothing forbidding a server from
* omitting those if it wants to.
*/
return NULL;
}
I've decided that trying to do wildcards in PSFTP as a special case of directory recursion was a strategic error: it obfuscates sftp_{get,put}_file(), and also it makes it very hard to handle subdirectory wildcards such as `foo/*'. Accordingly, here's a completely different approach, in which sftp_{get,put}_file() are still responsible for directory recursion, but wildcards are expanded in sftp_general_{get,put}() before being passed thereto. Subdirectory wildcards are now handled consistently across Unix, Windows and the remote server. [originally from svn r5045]
2004-12-30 13:51:37 +00:00
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
swcm->namepos = 0;
}
I've decided that trying to do wildcards in PSFTP as a special case of directory recursion was a strategic error: it obfuscates sftp_{get,put}_file(), and also it makes it very hard to handle subdirectory wildcards such as `foo/*'. Accordingly, here's a completely different approach, in which sftp_{get,put}_file() are still responsible for directory recursion, but wildcards are expanded in sftp_general_{get,put}() before being passed thereto. Subdirectory wildcards are now handled consistently across Unix, Windows and the remote server. [originally from svn r5045]
2004-12-30 13:51:37 +00:00
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
assert(swcm->names && swcm->namepos < swcm->names->nnames);
I've decided that trying to do wildcards in PSFTP as a special case of directory recursion was a strategic error: it obfuscates sftp_{get,put}_file(), and also it makes it very hard to handle subdirectory wildcards such as `foo/*'. Accordingly, here's a completely different approach, in which sftp_{get,put}_file() are still responsible for directory recursion, but wildcards are expanded in sftp_general_{get,put}() before being passed thereto. Subdirectory wildcards are now handled consistently across Unix, Windows and the remote server. [originally from svn r5045]
2004-12-30 13:51:37 +00:00
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
name = &swcm->names->names[swcm->namepos++];
I've decided that trying to do wildcards in PSFTP as a special case of directory recursion was a strategic error: it obfuscates sftp_{get,put}_file(), and also it makes it very hard to handle subdirectory wildcards such as `foo/*'. Accordingly, here's a completely different approach, in which sftp_{get,put}_file() are still responsible for directory recursion, but wildcards are expanded in sftp_general_{get,put}() before being passed thereto. Subdirectory wildcards are now handled consistently across Unix, Windows and the remote server. [originally from svn r5045]
2004-12-30 13:51:37 +00:00
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
if (!strcmp(name->filename, ".") || !strcmp(name->filename, ".."))
continue; /* expected bad filenames */
I've decided that trying to do wildcards in PSFTP as a special case of directory recursion was a strategic error: it obfuscates sftp_{get,put}_file(), and also it makes it very hard to handle subdirectory wildcards such as `foo/*'. Accordingly, here's a completely different approach, in which sftp_{get,put}_file() are still responsible for directory recursion, but wildcards are expanded in sftp_general_{get,put}() before being passed thereto. Subdirectory wildcards are now handled consistently across Unix, Windows and the remote server. [originally from svn r5045]
2004-12-30 13:51:37 +00:00
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
if (!vet_filename(name->filename)) {
File transfer tools: sanitise remote filenames and stderr. This commit adds sanitisation to PSCP and PSFTP in the same style as I've just put it into Plink. This time, standard error is sanitised without reference to whether it's redirected (at least unless you give an override option), on the basis that where Plink is _sometimes_ an SSH transport for some other protocol, PSCP and PSFTP _always_ are. But also, the sanitiser is run over any remote filename sent by the server, substituting ? for any control characters it finds. That removes another avenue for the server to deliberately confuse the display. This commit fixes our bug 'pscp-unsanitised-server-output', aka the two notional 'vulnerabilities' CVE-2019-6109 and CVE-2019-6110. (Although we regard those in isolation as only bugs, not serious vulnerabilities, because their main threat was in hiding the evidence of a server having exploited other more serious vulns that we never had.)
2019-02-20 07:09:10 +00:00
with_stripctrl(san, name->filename)
printf("ignoring potentially dangerous server-"
"supplied filename '%s'\n", san);
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
continue; /* unexpected bad filename */
}
I've decided that trying to do wildcards in PSFTP as a special case of directory recursion was a strategic error: it obfuscates sftp_{get,put}_file(), and also it makes it very hard to handle subdirectory wildcards such as `foo/*'. Accordingly, here's a completely different approach, in which sftp_{get,put}_file() are still responsible for directory recursion, but wildcards are expanded in sftp_general_{get,put}() before being passed thereto. Subdirectory wildcards are now handled consistently across Unix, Windows and the remote server. [originally from svn r5045]
2004-12-30 13:51:37 +00:00
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
if (!wc_match(swcm->wildcard, name->filename))
continue; /* doesn't match the wildcard */
I've decided that trying to do wildcards in PSFTP as a special case of directory recursion was a strategic error: it obfuscates sftp_{get,put}_file(), and also it makes it very hard to handle subdirectory wildcards such as `foo/*'. Accordingly, here's a completely different approach, in which sftp_{get,put}_file() are still responsible for directory recursion, but wildcards are expanded in sftp_general_{get,put}() before being passed thereto. Subdirectory wildcards are now handled consistently across Unix, Windows and the remote server. [originally from svn r5045]
2004-12-30 13:51:37 +00:00
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
/*
* We have a working filename. Return it.
*/
return dupprintf("%s%s%s", swcm->prefix,
(!swcm->prefix[0] ||
swcm->prefix[strlen(swcm->prefix)-1]=='/' ?
"" : "/"),
name->filename);
I've decided that trying to do wildcards in PSFTP as a special case of directory recursion was a strategic error: it obfuscates sftp_{get,put}_file(), and also it makes it very hard to handle subdirectory wildcards such as `foo/*'. Accordingly, here's a completely different approach, in which sftp_{get,put}_file() are still responsible for directory recursion, but wildcards are expanded in sftp_general_{get,put}() before being passed thereto. Subdirectory wildcards are now handled consistently across Unix, Windows and the remote server. [originally from svn r5045]
2004-12-30 13:51:37 +00:00
}
}
void sftp_finish_wildcard_matching(SftpWildcardMatcher *swcm)
{
struct sftp_packet *pktin;
Clean up handling of the return value from sftp_find_request. In many places we simply enforce by assertion that it will match the request we sent out a moment ago: in fact it can also return NULL, so it makes more sense to report a proper error message if it doesn't return the expected value, and while we're at it, have that error message whatever message was helpfully left in fxp_error() by sftp_find_request when it failed. To do this, I've written a centralised function in psftp.c called sftp_wait_for_reply, which is handed a request that's just been sent out and deals with the mechanics of waiting for its reply, returning the reply when it arrives, and aborting with a sensible error if anything else arrives instead. The numerous sites in psftp.c which called sftp_find_request have all been rewritten to do this instead, and as a side effect they now look more sensible. The only other uses of sftp_find_request were in xfer_*load_gotpkt, which had to be tweaked in its own way. While I'm here, also fix memory management in sftp_find_request, which was freeing its input packet on some but not all error return paths. [originally from svn r9894]
2013-07-06 20:43:21 +00:00
struct sftp_request *req;
I've decided that trying to do wildcards in PSFTP as a special case of directory recursion was a strategic error: it obfuscates sftp_{get,put}_file(), and also it makes it very hard to handle subdirectory wildcards such as `foo/*'. Accordingly, here's a completely different approach, in which sftp_{get,put}_file() are still responsible for directory recursion, but wildcards are expanded in sftp_general_{get,put}() before being passed thereto. Subdirectory wildcards are now handled consistently across Unix, Windows and the remote server. [originally from svn r5045]
2004-12-30 13:51:37 +00:00
Clean up handling of the return value from sftp_find_request. In many places we simply enforce by assertion that it will match the request we sent out a moment ago: in fact it can also return NULL, so it makes more sense to report a proper error message if it doesn't return the expected value, and while we're at it, have that error message whatever message was helpfully left in fxp_error() by sftp_find_request when it failed. To do this, I've written a centralised function in psftp.c called sftp_wait_for_reply, which is handed a request that's just been sent out and deals with the mechanics of waiting for its reply, returning the reply when it arrives, and aborting with a sensible error if anything else arrives instead. The numerous sites in psftp.c which called sftp_find_request have all been rewritten to do this instead, and as a side effect they now look more sensible. The only other uses of sftp_find_request were in xfer_*load_gotpkt, which had to be tweaked in its own way. While I'm here, also fix memory management in sftp_find_request, which was freeing its input packet on some but not all error return paths. [originally from svn r9894]
2013-07-06 20:43:21 +00:00
req = fxp_close_send(swcm->dirh);
pktin = sftp_wait_for_reply(req);
fxp_close_recv(pktin, req);
I've decided that trying to do wildcards in PSFTP as a special case of directory recursion was a strategic error: it obfuscates sftp_{get,put}_file(), and also it makes it very hard to handle subdirectory wildcards such as `foo/*'. Accordingly, here's a completely different approach, in which sftp_{get,put}_file() are still responsible for directory recursion, but wildcards are expanded in sftp_general_{get,put}() before being passed thereto. Subdirectory wildcards are now handled consistently across Unix, Windows and the remote server. [originally from svn r5045]
2004-12-30 13:51:37 +00:00
if (swcm->names)
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
fxp_free_names(swcm->names);
I've decided that trying to do wildcards in PSFTP as a special case of directory recursion was a strategic error: it obfuscates sftp_{get,put}_file(), and also it makes it very hard to handle subdirectory wildcards such as `foo/*'. Accordingly, here's a completely different approach, in which sftp_{get,put}_file() are still responsible for directory recursion, but wildcards are expanded in sftp_general_{get,put}() before being passed thereto. Subdirectory wildcards are now handled consistently across Unix, Windows and the remote server. [originally from svn r5045]
2004-12-30 13:51:37 +00:00
sfree(swcm->prefix);
sfree(swcm->wildcard);
sfree(swcm);
}
"Nirwana Nirwana" points out that mget, mput and ls are not the only PSFTP commands that can make good use of wildcards! Now implemented wildcard support in rmdir, rm, mv and chmod. [originally from svn r5055]
2005-01-01 12:34:32 +00:00
/*
* General function to match a potential wildcard in a filename
* argument and iterate over every matching file. Used in several
* PSFTP commands (rmdir, rm, chmod, mv).
*/
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
bool wildcard_iterate(char *filename, bool (*func)(void *, char *), void *ctx)
"Nirwana Nirwana" points out that mget, mput and ls are not the only PSFTP commands that can make good use of wildcards! Now implemented wildcard support in rmdir, rm, mv and chmod. [originally from svn r5055]
2005-01-01 12:34:32 +00:00
{
char *unwcfname, *newname, *cname;
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
bool is_wc, toret;
"Nirwana Nirwana" points out that mget, mput and ls are not the only PSFTP commands that can make good use of wildcards! Now implemented wildcard support in rmdir, rm, mv and chmod. [originally from svn r5055]
2005-01-01 12:34:32 +00:00
unwcfname = snewn(strlen(filename)+1, char);
is_wc = !wc_unescape(unwcfname, filename);
if (is_wc) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
SftpWildcardMatcher *swcm = sftp_begin_wildcard_matching(filename);
bool matched = false;
sfree(unwcfname);
"Nirwana Nirwana" points out that mget, mput and ls are not the only PSFTP commands that can make good use of wildcards! Now implemented wildcard support in rmdir, rm, mv and chmod. [originally from svn r5055]
2005-01-01 12:34:32 +00:00
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
if (!swcm)
return false;
"Nirwana Nirwana" points out that mget, mput and ls are not the only PSFTP commands that can make good use of wildcards! Now implemented wildcard support in rmdir, rm, mv and chmod. [originally from svn r5055]
2005-01-01 12:34:32 +00:00
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
toret = true;
"Nirwana Nirwana" points out that mget, mput and ls are not the only PSFTP commands that can make good use of wildcards! Now implemented wildcard support in rmdir, rm, mv and chmod. [originally from svn r5055]
2005-01-01 12:34:32 +00:00
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
while ( (newname = sftp_wildcard_get_filename(swcm)) != NULL ) {
cname = canonify(newname);
Add an assortment of missing frees, and one missing file close. Mostly on error paths, although the one in PSFTP's wildcard_iterate will come up in normal usage. [originally from svn r9916]
2013-07-11 17:43:41 +00:00
sfree(newname);
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
matched = true;
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
if (!func(ctx, cname))
toret = false;
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
sfree(cname);
}
"Nirwana Nirwana" points out that mget, mput and ls are not the only PSFTP commands that can make good use of wildcards! Now implemented wildcard support in rmdir, rm, mv and chmod. [originally from svn r5055]
2005-01-01 12:34:32 +00:00
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
if (!matched) {
/* Politely warn the user that nothing matched. */
printf("%s: nothing matched\n", filename);
}
"Nirwana Nirwana" points out that mget, mput and ls are not the only PSFTP commands that can make good use of wildcards! Now implemented wildcard support in rmdir, rm, mv and chmod. [originally from svn r5055]
2005-01-01 12:34:32 +00:00
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
sftp_finish_wildcard_matching(swcm);
"Nirwana Nirwana" points out that mget, mput and ls are not the only PSFTP commands that can make good use of wildcards! Now implemented wildcard support in rmdir, rm, mv and chmod. [originally from svn r5055]
2005-01-01 12:34:32 +00:00
} else {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
cname = canonify(unwcfname);
toret = func(ctx, cname);
sfree(cname);
sfree(unwcfname);
"Nirwana Nirwana" points out that mget, mput and ls are not the only PSFTP commands that can make good use of wildcards! Now implemented wildcard support in rmdir, rm, mv and chmod. [originally from svn r5055]
2005-01-01 12:34:32 +00:00
}
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
return toret;
"Nirwana Nirwana" points out that mget, mput and ls are not the only PSFTP commands that can make good use of wildcards! Now implemented wildcard support in rmdir, rm, mv and chmod. [originally from svn r5055]
2005-01-01 12:34:32 +00:00
}
/*
* Handy helper function.
*/
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
bool is_wildcard(char *name)
"Nirwana Nirwana" points out that mget, mput and ls are not the only PSFTP commands that can make good use of wildcards! Now implemented wildcard support in rmdir, rm, mv and chmod. [originally from svn r5055]
2005-01-01 12:34:32 +00:00
{
char *unwcfname = snewn(strlen(name)+1, char);
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
bool is_wc = !wc_unescape(unwcfname, name);
"Nirwana Nirwana" points out that mget, mput and ls are not the only PSFTP commands that can make good use of wildcards! Now implemented wildcard support in rmdir, rm, mv and chmod. [originally from svn r5055]
2005-01-01 12:34:32 +00:00
sfree(unwcfname);
return is_wc;
}
Support for recursive file transfer in PSFTP. [originally from svn r4990] [this svn revision also touched putty-wishlist]
2004-12-16 16:37:37 +00:00
/* ----------------------------------------------------------------------
* Actual sftp commands.
*/
struct sftp_command {
char **words;
New array-growing macros: sgrowarray and sgrowarrayn. The idea of these is that they centralise the common idiom along the lines of if (logical_array_len >= physical_array_size) { physical_array_size = logical_array_len * 5 / 4 + 256; array = sresize(array, physical_array_size, ElementType); } which happens at a zillion call sites throughout this code base, with different random choices of the geometric factor and additive constant, sometimes forgetting them completely, and generally doing a lot of repeated work. The new macro sgrowarray(array,size,n) has the semantics: here are the array pointer and its physical size for you to modify, now please ensure that the nth element exists, so I can write into it. And sgrowarrayn(array,size,n,m) is the same except that it ensures that the array has size at least n+m (so sgrowarray is just the special case where m=1). Now that this is a single centralised implementation that will be used everywhere, I've also gone to more effort in the implementation, with careful overflow checks that would have been painful to put at all the previous call sites. This commit also switches over every use of sresize(), apart from a few where I really didn't think it would gain anything. A consequence of that is that a lot of array-size variables have to have their types changed to size_t, because the macros require that (they address-take the size to pass to the underlying function).
2019-02-28 20:07:30 +00:00
size_t nwords, wordssize;
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
int (*obey) (struct sftp_command *); /* returns <0 to quit */
Support for recursive file transfer in PSFTP. [originally from svn r4990] [this svn revision also touched putty-wishlist]
2004-12-16 16:37:37 +00:00
};
int sftp_cmd_null(struct sftp_command *cmd)
{
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
return 1; /* success */
Support for recursive file transfer in PSFTP. [originally from svn r4990] [this svn revision also touched putty-wishlist]
2004-12-16 16:37:37 +00:00
}
int sftp_cmd_unknown(struct sftp_command *cmd)
{
printf("psftp: unknown command \"%s\"\n", cmd->words[0]);
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
return 0; /* failure */
Support for recursive file transfer in PSFTP. [originally from svn r4990] [this svn revision also touched putty-wishlist]
2004-12-16 16:37:37 +00:00
}
int sftp_cmd_quit(struct sftp_command *cmd)
{
return -1;
}
Implement the `close' command, which terminates an SFTP session but does not quit PSFTP, so you can then issue another `open' to connect to somewhere else. This has apparently been trivial for some time, for exactly the same reasons that `reuse-windows' was so easy, but it hadn't occurred to me to actually do it until now. [originally from svn r4994]
2004-12-16 19:19:59 +00:00
int sftp_cmd_close(struct sftp_command *cmd)
{
Turn Backend into a sensible classoid. Nearly every part of the code that ever handles a full backend structure has historically done it using a pair of pointer variables, one pointing at a constant struct full of function pointers, and the other pointing to a 'void *' state object that's passed to each of those. While I'm modernising the rest of the code, this seems like a good time to turn that into the same more or less type-safe and less cumbersome system as I'm using for other parts of the code, such as Socket, Plug, BinaryPacketProtocol and so forth: the Backend structure contains a vtable pointer, and a system of macro wrappers handles dispatching through that vtable.
2018-09-11 15:23:38 +00:00
if (!backend) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
not_connected();
return 0;
Implement the `close' command, which terminates an SFTP session but does not quit PSFTP, so you can then issue another `open' to connect to somewhere else. This has apparently been trivial for some time, for exactly the same reasons that `reuse-windows' was so easy, but it hadn't occurred to me to actually do it until now. [originally from svn r4994]
2004-12-16 19:19:59 +00:00
}
Turn Backend into a sensible classoid. Nearly every part of the code that ever handles a full backend structure has historically done it using a pair of pointer variables, one pointing at a constant struct full of function pointers, and the other pointing to a 'void *' state object that's passed to each of those. While I'm modernising the rest of the code, this seems like a good time to turn that into the same more or less type-safe and less cumbersome system as I'm using for other parts of the code, such as Socket, Plug, BinaryPacketProtocol and so forth: the Backend structure contains a vtable pointer, and a system of macro wrappers handles dispatching through that vtable.
2018-09-11 15:23:38 +00:00
if (backend_connected(backend)) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
char ch;
Rework special-commands system to add an integer argument. In order to list cross-certifiable host keys in the GUI specials menu, the SSH backend has been inventing new values on the end of the Telnet_Special enumeration, starting from the value TS_LOCALSTART. This is inelegant, and also makes it awkward to break up special handlers (e.g. to dispatch different specials to different SSH layers), since if all you know about a special is that it's somewhere in the TS_LOCALSTART+n space, you can't tell what _general kind_ of thing it is. Also, if I ever need another open-ended set of specials in future, I'll have to remember which TS_LOCALSTART+n codes are in which set. So here's a revamp that causes every special to take an extra integer argument. For all previously numbered specials, this argument is passed as zero and ignored, but there's a new main special code for SSH host key cross-certification, in which the integer argument is an index into the backend's list of available keys. TS_LOCALSTART is now a thing of the past: if I need any other open-ended sets of specials in future, I can add a new top-level code with a nicely separated space of arguments. While I'm at it, I've removed the legacy misnomer 'Telnet_Special' from the code completely; the enum is now SessionSpecialCode, the struct containing full details of a menu entry is SessionSpecial, and the enum values now start SS_ rather than TS_.
2018-09-24 08:35:52 +00:00
backend_special(backend, SS_EOF, 0);
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
sent_eof = true;
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
sftp_recvdata(&ch, 1);
Implement the `close' command, which terminates an SFTP session but does not quit PSFTP, so you can then issue another `open' to connect to somewhere else. This has apparently been trivial for some time, for exactly the same reasons that `reuse-windows' was so easy, but it hadn't occurred to me to actually do it until now. [originally from svn r4994]
2004-12-16 19:19:59 +00:00
}
do_sftp_cleanup();
return 0;
}
Fall back to not sorting large dirs in pscp -ls or psftp 'ls'. This mitigates a borderline-DoS in which a malicious SFTP server sends a ludicrously large number of file names in response to a SFTP opendir/readdir request sequence, causing the client to buffer them all and use up all the system's memory simply so that it can produce the output in sorted order. I call it a 'borderline' DoS because it's very likely that this is the same server that you'll also trust to actually send you the _contents_ of some entire file or directory, in which case, if they want to DoS you they can do that anyway at that point and you have no way to tell a legit very large file from a bad one. So it's unclear to me that anyone would get any real advantage out of 'exploiting' this that they couldn't have got anyway by other means. That said, it may have practical benefits in the occasional case. Imagine a _legit_ gigantic directory (something like a maildir, perhaps, and perhaps stored on a server-side filesystem specialising in not choking on really huge single directories), together with a client workflow that involves listing the whole directory but then downloading only one particular file in it. For the moment, the threshold size is fixed at 8Mb of total data (counting the lengths of the file names as well as just the number of files). If that needs to become configurable later, we can always add an option.
2019-05-15 13:57:06 +00:00
void list_directory_from_sftp_warn_unsorted(void)
{
printf("Directory is too large to sort; writing file names unsorted\n");
}
void list_directory_from_sftp_print(struct fxp_name *name)
{
with_stripctrl(san, name->longname)
printf("%s\n", san);
}
Support for recursive file transfer in PSFTP. [originally from svn r4990] [this svn revision also touched putty-wishlist]
2004-12-16 16:37:37 +00:00
/*
* List a directory. If no arguments are given, list pwd; otherwise
* list the directory given in words[1].
*/
int sftp_cmd_ls(struct sftp_command *cmd)
{
struct fxp_handle *dirh;
struct fxp_names *names;
Giant const-correctness patch of doom! Having found a lot of unfixed constness issues in recent development, I thought perhaps it was time to get proactive, so I compiled the whole codebase with -Wwrite-strings. That turned up a huge load of const problems, which I've fixed in this commit: the Unix build now goes cleanly through with -Wwrite-strings, and the Windows build is as close as I could get it (there are some lingering issues due to occasional Windows API functions like AcquireCredentialsHandle not having the right constness). Notable fallout beyond the purely mechanical changing of types: - the stuff saved by cmdline_save_param() is now explicitly dupstr()ed, and freed in cmdline_run_saved. - I couldn't make both string arguments to cmdline_process_param() const, because it intentionally writes to one of them in the case where it's the argument to -pw (in the vain hope of being at least slightly friendly to 'ps'), so elsewhere I had to temporarily dupstr() something for the sake of passing it to that function - I had to invent a silly parallel version of const_cmp() so I could pass const string literals in to lookup functions. - stripslashes() in pscp.c and psftp.c has the annoying strchr nature
2015-05-15 10:15:42 +00:00
const char *dir;
char *cdir, *unwcdir, *wildcard;
Support for recursive file transfer in PSFTP. [originally from svn r4990] [this svn revision also touched putty-wishlist]
2004-12-16 16:37:37 +00:00
struct sftp_packet *pktin;
Clean up handling of the return value from sftp_find_request. In many places we simply enforce by assertion that it will match the request we sent out a moment ago: in fact it can also return NULL, so it makes more sense to report a proper error message if it doesn't return the expected value, and while we're at it, have that error message whatever message was helpfully left in fxp_error() by sftp_find_request when it failed. To do this, I've written a centralised function in psftp.c called sftp_wait_for_reply, which is handed a request that's just been sent out and deals with the mechanics of waiting for its reply, returning the reply when it arrives, and aborting with a sensible error if anything else arrives instead. The numerous sites in psftp.c which called sftp_find_request have all been rewritten to do this instead, and as a side effect they now look more sensible. The only other uses of sftp_find_request were in xfer_*load_gotpkt, which had to be tweaked in its own way. While I'm here, also fix memory management in sftp_find_request, which was freeing its input packet on some but not all error return paths. [originally from svn r9894]
2013-07-06 20:43:21 +00:00
struct sftp_request *req;
Support for recursive file transfer in PSFTP. [originally from svn r4990] [this svn revision also touched putty-wishlist]
2004-12-16 16:37:37 +00:00
Turn Backend into a sensible classoid. Nearly every part of the code that ever handles a full backend structure has historically done it using a pair of pointer variables, one pointing at a constant struct full of function pointers, and the other pointing to a 'void *' state object that's passed to each of those. While I'm modernising the rest of the code, this seems like a good time to turn that into the same more or less type-safe and less cumbersome system as I'm using for other parts of the code, such as Socket, Plug, BinaryPacketProtocol and so forth: the Backend structure contains a vtable pointer, and a system of macro wrappers handles dispatching through that vtable.
2018-09-11 15:23:38 +00:00
if (!backend) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
not_connected();
return 0;
Support for recursive file transfer in PSFTP. [originally from svn r4990] [this svn revision also touched putty-wishlist]
2004-12-16 16:37:37 +00:00
}
if (cmd->nwords < 2)
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
dir = ".";
Support for recursive file transfer in PSFTP. [originally from svn r4990] [this svn revision also touched putty-wishlist]
2004-12-16 16:37:37 +00:00
else
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
dir = cmd->words[1];
Support for recursive file transfer in PSFTP. [originally from svn r4990] [this svn revision also touched putty-wishlist]
2004-12-16 16:37:37 +00:00
Wildcards in `ls'. I think that completes `psftp-multi'. Woo! [originally from svn r4992] [this svn revision also touched putty-wishlist]
2004-12-16 17:45:29 +00:00
unwcdir = snewn(1 + strlen(dir), char);
if (wc_unescape(unwcdir, dir)) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
dir = unwcdir;
wildcard = NULL;
Wildcards in `ls'. I think that completes `psftp-multi'. Woo! [originally from svn r4992] [this svn revision also touched putty-wishlist]
2004-12-16 17:45:29 +00:00
} else {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
char *tmpdir;
int len;
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
bool check;
Wildcards in `ls'. I think that completes `psftp-multi'. Woo! [originally from svn r4992] [this svn revision also touched putty-wishlist]
2004-12-16 17:45:29 +00:00
Fix another giant batch of resource leaks. (Mostly memory, but there's one missing fclose too.) [originally from svn r9919]
2013-07-14 10:46:07 +00:00
sfree(unwcdir);
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
wildcard = stripslashes(dir, false);
unwcdir = dupstr(dir);
len = wildcard - dir;
unwcdir[len] = '\0';
if (len > 0 && unwcdir[len-1] == '/')
unwcdir[len-1] = '\0';
tmpdir = snewn(1 + len, char);
check = wc_unescape(tmpdir, unwcdir);
sfree(tmpdir);
if (!check) {
printf("Multiple-level wildcards are not supported\n");
sfree(unwcdir);
return 0;
}
dir = unwcdir;
Wildcards in `ls'. I think that completes `psftp-multi'. Woo! [originally from svn r4992] [this svn revision also touched putty-wishlist]
2004-12-16 17:45:29 +00:00
}
Support for recursive file transfer in PSFTP. [originally from svn r4990] [this svn revision also touched putty-wishlist]
2004-12-16 16:37:37 +00:00
cdir = canonify(dir);
File transfer tools: sanitise remote filenames and stderr. This commit adds sanitisation to PSCP and PSFTP in the same style as I've just put it into Plink. This time, standard error is sanitised without reference to whether it's redirected (at least unless you give an override option), on the basis that where Plink is _sometimes_ an SSH transport for some other protocol, PSCP and PSFTP _always_ are. But also, the sanitiser is run over any remote filename sent by the server, substituting ? for any control characters it finds. That removes another avenue for the server to deliberately confuse the display. This commit fixes our bug 'pscp-unsanitised-server-output', aka the two notional 'vulnerabilities' CVE-2019-6109 and CVE-2019-6110. (Although we regard those in isolation as only bugs, not serious vulnerabilities, because their main threat was in hiding the evidence of a server having exploited other more serious vulns that we never had.)
2019-02-20 07:09:10 +00:00
with_stripctrl(san, cdir)
printf("Listing directory %s\n", san);
Support for recursive file transfer in PSFTP. [originally from svn r4990] [this svn revision also touched putty-wishlist]
2004-12-16 16:37:37 +00:00
Clean up handling of the return value from sftp_find_request. In many places we simply enforce by assertion that it will match the request we sent out a moment ago: in fact it can also return NULL, so it makes more sense to report a proper error message if it doesn't return the expected value, and while we're at it, have that error message whatever message was helpfully left in fxp_error() by sftp_find_request when it failed. To do this, I've written a centralised function in psftp.c called sftp_wait_for_reply, which is handed a request that's just been sent out and deals with the mechanics of waiting for its reply, returning the reply when it arrives, and aborting with a sensible error if anything else arrives instead. The numerous sites in psftp.c which called sftp_find_request have all been rewritten to do this instead, and as a side effect they now look more sensible. The only other uses of sftp_find_request were in xfer_*load_gotpkt, which had to be tweaked in its own way. While I'm here, also fix memory management in sftp_find_request, which was freeing its input packet on some but not all error return paths. [originally from svn r9894]
2013-07-06 20:43:21 +00:00
req = fxp_opendir_send(cdir);
pktin = sftp_wait_for_reply(req);
dirh = fxp_opendir_recv(pktin, req);
Support for recursive file transfer in PSFTP. [originally from svn r4990] [this svn revision also touched putty-wishlist]
2004-12-16 16:37:37 +00:00
if (dirh == NULL) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
printf("Unable to open %s: %s\n", dir, fxp_error());
sfree(cdir);
sfree(unwcdir);
return 0;
Support for recursive file transfer in PSFTP. [originally from svn r4990] [this svn revision also touched putty-wishlist]
2004-12-16 16:37:37 +00:00
} else {
Fall back to not sorting large dirs in pscp -ls or psftp 'ls'. This mitigates a borderline-DoS in which a malicious SFTP server sends a ludicrously large number of file names in response to a SFTP opendir/readdir request sequence, causing the client to buffer them all and use up all the system's memory simply so that it can produce the output in sorted order. I call it a 'borderline' DoS because it's very likely that this is the same server that you'll also trust to actually send you the _contents_ of some entire file or directory, in which case, if they want to DoS you they can do that anyway at that point and you have no way to tell a legit very large file from a bad one. So it's unclear to me that anyone would get any real advantage out of 'exploiting' this that they couldn't have got anyway by other means. That said, it may have practical benefits in the occasional case. Imagine a _legit_ gigantic directory (something like a maildir, perhaps, and perhaps stored on a server-side filesystem specialising in not choking on really huge single directories), together with a client workflow that involves listing the whole directory but then downloading only one particular file in it. For the moment, the threshold size is fixed at 8Mb of total data (counting the lengths of the file names as well as just the number of files). If that needs to become configurable later, we can always add an option.
2019-05-15 13:57:06 +00:00
struct list_directory_from_sftp_ctx *ctx =
list_directory_from_sftp_new();
Support for recursive file transfer in PSFTP. [originally from svn r4990] [this svn revision also touched putty-wishlist]
2004-12-16 16:37:37 +00:00
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
while (1) {
Support for recursive file transfer in PSFTP. [originally from svn r4990] [this svn revision also touched putty-wishlist]
2004-12-16 16:37:37 +00:00
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
req = fxp_readdir_send(dirh);
Clean up handling of the return value from sftp_find_request. In many places we simply enforce by assertion that it will match the request we sent out a moment ago: in fact it can also return NULL, so it makes more sense to report a proper error message if it doesn't return the expected value, and while we're at it, have that error message whatever message was helpfully left in fxp_error() by sftp_find_request when it failed. To do this, I've written a centralised function in psftp.c called sftp_wait_for_reply, which is handed a request that's just been sent out and deals with the mechanics of waiting for its reply, returning the reply when it arrives, and aborting with a sensible error if anything else arrives instead. The numerous sites in psftp.c which called sftp_find_request have all been rewritten to do this instead, and as a side effect they now look more sensible. The only other uses of sftp_find_request were in xfer_*load_gotpkt, which had to be tweaked in its own way. While I'm here, also fix memory management in sftp_find_request, which was freeing its input packet on some but not all error return paths. [originally from svn r9894]
2013-07-06 20:43:21 +00:00
pktin = sftp_wait_for_reply(req);
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
names = fxp_readdir_recv(pktin, req);
if (names == NULL) {
if (fxp_error_type() == SSH_FX_EOF)
break;
printf("Reading directory %s: %s\n", dir, fxp_error());
break;
}
if (names->nnames == 0) {
fxp_free_names(names);
break;
}
for (size_t i = 0; i < names->nnames; i++)
if (!wildcard || wc_match(wildcard, names->names[i].filename))
Fall back to not sorting large dirs in pscp -ls or psftp 'ls'. This mitigates a borderline-DoS in which a malicious SFTP server sends a ludicrously large number of file names in response to a SFTP opendir/readdir request sequence, causing the client to buffer them all and use up all the system's memory simply so that it can produce the output in sorted order. I call it a 'borderline' DoS because it's very likely that this is the same server that you'll also trust to actually send you the _contents_ of some entire file or directory, in which case, if they want to DoS you they can do that anyway at that point and you have no way to tell a legit very large file from a bad one. So it's unclear to me that anyone would get any real advantage out of 'exploiting' this that they couldn't have got anyway by other means. That said, it may have practical benefits in the occasional case. Imagine a _legit_ gigantic directory (something like a maildir, perhaps, and perhaps stored on a server-side filesystem specialising in not choking on really huge single directories), together with a client workflow that involves listing the whole directory but then downloading only one particular file in it. For the moment, the threshold size is fixed at 8Mb of total data (counting the lengths of the file names as well as just the number of files). If that needs to become configurable later, we can always add an option.
2019-05-15 13:57:06 +00:00
list_directory_from_sftp_feed(ctx, &names->names[i]);
Support for recursive file transfer in PSFTP. [originally from svn r4990] [this svn revision also touched putty-wishlist]
2004-12-16 16:37:37 +00:00
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
fxp_free_names(names);
}
Fall back to not sorting large dirs in pscp -ls or psftp 'ls'. This mitigates a borderline-DoS in which a malicious SFTP server sends a ludicrously large number of file names in response to a SFTP opendir/readdir request sequence, causing the client to buffer them all and use up all the system's memory simply so that it can produce the output in sorted order. I call it a 'borderline' DoS because it's very likely that this is the same server that you'll also trust to actually send you the _contents_ of some entire file or directory, in which case, if they want to DoS you they can do that anyway at that point and you have no way to tell a legit very large file from a bad one. So it's unclear to me that anyone would get any real advantage out of 'exploiting' this that they couldn't have got anyway by other means. That said, it may have practical benefits in the occasional case. Imagine a _legit_ gigantic directory (something like a maildir, perhaps, and perhaps stored on a server-side filesystem specialising in not choking on really huge single directories), together with a client workflow that involves listing the whole directory but then downloading only one particular file in it. For the moment, the threshold size is fixed at 8Mb of total data (counting the lengths of the file names as well as just the number of files). If that needs to become configurable later, we can always add an option.
2019-05-15 13:57:06 +00:00
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
req = fxp_close_send(dirh);
Clean up handling of the return value from sftp_find_request. In many places we simply enforce by assertion that it will match the request we sent out a moment ago: in fact it can also return NULL, so it makes more sense to report a proper error message if it doesn't return the expected value, and while we're at it, have that error message whatever message was helpfully left in fxp_error() by sftp_find_request when it failed. To do this, I've written a centralised function in psftp.c called sftp_wait_for_reply, which is handed a request that's just been sent out and deals with the mechanics of waiting for its reply, returning the reply when it arrives, and aborting with a sensible error if anything else arrives instead. The numerous sites in psftp.c which called sftp_find_request have all been rewritten to do this instead, and as a side effect they now look more sensible. The only other uses of sftp_find_request were in xfer_*load_gotpkt, which had to be tweaked in its own way. While I'm here, also fix memory management in sftp_find_request, which was freeing its input packet on some but not all error return paths. [originally from svn r9894]
2013-07-06 20:43:21 +00:00
pktin = sftp_wait_for_reply(req);
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
fxp_close_recv(pktin, req);
Support for recursive file transfer in PSFTP. [originally from svn r4990] [this svn revision also touched putty-wishlist]
2004-12-16 16:37:37 +00:00
Fall back to not sorting large dirs in pscp -ls or psftp 'ls'. This mitigates a borderline-DoS in which a malicious SFTP server sends a ludicrously large number of file names in response to a SFTP opendir/readdir request sequence, causing the client to buffer them all and use up all the system's memory simply so that it can produce the output in sorted order. I call it a 'borderline' DoS because it's very likely that this is the same server that you'll also trust to actually send you the _contents_ of some entire file or directory, in which case, if they want to DoS you they can do that anyway at that point and you have no way to tell a legit very large file from a bad one. So it's unclear to me that anyone would get any real advantage out of 'exploiting' this that they couldn't have got anyway by other means. That said, it may have practical benefits in the occasional case. Imagine a _legit_ gigantic directory (something like a maildir, perhaps, and perhaps stored on a server-side filesystem specialising in not choking on really huge single directories), together with a client workflow that involves listing the whole directory but then downloading only one particular file in it. For the moment, the threshold size is fixed at 8Mb of total data (counting the lengths of the file names as well as just the number of files). If that needs to become configurable later, we can always add an option.
2019-05-15 13:57:06 +00:00
list_directory_from_sftp_finish(ctx);
list_directory_from_sftp_free(ctx);
Support for recursive file transfer in PSFTP. [originally from svn r4990] [this svn revision also touched putty-wishlist]
2004-12-16 16:37:37 +00:00
}
sfree(cdir);
Wildcards in `ls'. I think that completes `psftp-multi'. Woo! [originally from svn r4992] [this svn revision also touched putty-wishlist]
2004-12-16 17:45:29 +00:00
sfree(unwcdir);
Support for recursive file transfer in PSFTP. [originally from svn r4990] [this svn revision also touched putty-wishlist]
2004-12-16 16:37:37 +00:00
return 1;
}
/*
* Change directories. We do this by canonifying the new name, then
* trying to OPENDIR it. Only if that succeeds do we set the new pwd.
*/
int sftp_cmd_cd(struct sftp_command *cmd)
{
struct fxp_handle *dirh;
struct sftp_packet *pktin;
Clean up handling of the return value from sftp_find_request. In many places we simply enforce by assertion that it will match the request we sent out a moment ago: in fact it can also return NULL, so it makes more sense to report a proper error message if it doesn't return the expected value, and while we're at it, have that error message whatever message was helpfully left in fxp_error() by sftp_find_request when it failed. To do this, I've written a centralised function in psftp.c called sftp_wait_for_reply, which is handed a request that's just been sent out and deals with the mechanics of waiting for its reply, returning the reply when it arrives, and aborting with a sensible error if anything else arrives instead. The numerous sites in psftp.c which called sftp_find_request have all been rewritten to do this instead, and as a side effect they now look more sensible. The only other uses of sftp_find_request were in xfer_*load_gotpkt, which had to be tweaked in its own way. While I'm here, also fix memory management in sftp_find_request, which was freeing its input packet on some but not all error return paths. [originally from svn r9894]
2013-07-06 20:43:21 +00:00
struct sftp_request *req;
Support for recursive file transfer in PSFTP. [originally from svn r4990] [this svn revision also touched putty-wishlist]
2004-12-16 16:37:37 +00:00
char *dir;
Turn Backend into a sensible classoid. Nearly every part of the code that ever handles a full backend structure has historically done it using a pair of pointer variables, one pointing at a constant struct full of function pointers, and the other pointing to a 'void *' state object that's passed to each of those. While I'm modernising the rest of the code, this seems like a good time to turn that into the same more or less type-safe and less cumbersome system as I'm using for other parts of the code, such as Socket, Plug, BinaryPacketProtocol and so forth: the Backend structure contains a vtable pointer, and a system of macro wrappers handles dispatching through that vtable.
2018-09-11 15:23:38 +00:00
if (!backend) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
not_connected();
return 0;
Support for recursive file transfer in PSFTP. [originally from svn r4990] [this svn revision also touched putty-wishlist]
2004-12-16 16:37:37 +00:00
}
if (cmd->nwords < 2)
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
dir = dupstr(homedir);
resolve couple of issues found by cppcheck: [psftp.c:1135] -> [psftp.c:1134]: (warning) Either the condition '!dir' is redundant or there is possible null pointer dereference: dir. [psftp.c:1420] -> [psftp.c:1419]: (warning) Either the condition '!dir' is redundant or there is possible null pointer dereference: dir.
2017-06-19 16:39:32 +00:00
else {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
dir = canonify(cmd->words[1]);
Support for recursive file transfer in PSFTP. [originally from svn r4990] [this svn revision also touched putty-wishlist]
2004-12-16 16:37:37 +00:00
}
Clean up handling of the return value from sftp_find_request. In many places we simply enforce by assertion that it will match the request we sent out a moment ago: in fact it can also return NULL, so it makes more sense to report a proper error message if it doesn't return the expected value, and while we're at it, have that error message whatever message was helpfully left in fxp_error() by sftp_find_request when it failed. To do this, I've written a centralised function in psftp.c called sftp_wait_for_reply, which is handed a request that's just been sent out and deals with the mechanics of waiting for its reply, returning the reply when it arrives, and aborting with a sensible error if anything else arrives instead. The numerous sites in psftp.c which called sftp_find_request have all been rewritten to do this instead, and as a side effect they now look more sensible. The only other uses of sftp_find_request were in xfer_*load_gotpkt, which had to be tweaked in its own way. While I'm here, also fix memory management in sftp_find_request, which was freeing its input packet on some but not all error return paths. [originally from svn r9894]
2013-07-06 20:43:21 +00:00
req = fxp_opendir_send(dir);
pktin = sftp_wait_for_reply(req);
dirh = fxp_opendir_recv(pktin, req);
Support for recursive file transfer in PSFTP. [originally from svn r4990] [this svn revision also touched putty-wishlist]
2004-12-16 16:37:37 +00:00
if (!dirh) {
File transfer tools: sanitise remote filenames and stderr. This commit adds sanitisation to PSCP and PSFTP in the same style as I've just put it into Plink. This time, standard error is sanitised without reference to whether it's redirected (at least unless you give an override option), on the basis that where Plink is _sometimes_ an SSH transport for some other protocol, PSCP and PSFTP _always_ are. But also, the sanitiser is run over any remote filename sent by the server, substituting ? for any control characters it finds. That removes another avenue for the server to deliberately confuse the display. This commit fixes our bug 'pscp-unsanitised-server-output', aka the two notional 'vulnerabilities' CVE-2019-6109 and CVE-2019-6110. (Although we regard those in isolation as only bugs, not serious vulnerabilities, because their main threat was in hiding the evidence of a server having exploited other more serious vulns that we never had.)
2019-02-20 07:09:10 +00:00
with_stripctrl(san, dir)
printf("Directory %s: %s\n", san, fxp_error());
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
sfree(dir);
return 0;
Support for recursive file transfer in PSFTP. [originally from svn r4990] [this svn revision also touched putty-wishlist]
2004-12-16 16:37:37 +00:00
}
Clean up handling of the return value from sftp_find_request. In many places we simply enforce by assertion that it will match the request we sent out a moment ago: in fact it can also return NULL, so it makes more sense to report a proper error message if it doesn't return the expected value, and while we're at it, have that error message whatever message was helpfully left in fxp_error() by sftp_find_request when it failed. To do this, I've written a centralised function in psftp.c called sftp_wait_for_reply, which is handed a request that's just been sent out and deals with the mechanics of waiting for its reply, returning the reply when it arrives, and aborting with a sensible error if anything else arrives instead. The numerous sites in psftp.c which called sftp_find_request have all been rewritten to do this instead, and as a side effect they now look more sensible. The only other uses of sftp_find_request were in xfer_*load_gotpkt, which had to be tweaked in its own way. While I'm here, also fix memory management in sftp_find_request, which was freeing its input packet on some but not all error return paths. [originally from svn r9894]
2013-07-06 20:43:21 +00:00
req = fxp_close_send(dirh);
pktin = sftp_wait_for_reply(req);
fxp_close_recv(pktin, req);
Support for recursive file transfer in PSFTP. [originally from svn r4990] [this svn revision also touched putty-wishlist]
2004-12-16 16:37:37 +00:00
sfree(pwd);
pwd = dir;
File transfer tools: sanitise remote filenames and stderr. This commit adds sanitisation to PSCP and PSFTP in the same style as I've just put it into Plink. This time, standard error is sanitised without reference to whether it's redirected (at least unless you give an override option), on the basis that where Plink is _sometimes_ an SSH transport for some other protocol, PSCP and PSFTP _always_ are. But also, the sanitiser is run over any remote filename sent by the server, substituting ? for any control characters it finds. That removes another avenue for the server to deliberately confuse the display. This commit fixes our bug 'pscp-unsanitised-server-output', aka the two notional 'vulnerabilities' CVE-2019-6109 and CVE-2019-6110. (Although we regard those in isolation as only bugs, not serious vulnerabilities, because their main threat was in hiding the evidence of a server having exploited other more serious vulns that we never had.)
2019-02-20 07:09:10 +00:00
with_stripctrl(san, pwd)
printf("Remote directory is now %s\n", san);
Support for recursive file transfer in PSFTP. [originally from svn r4990] [this svn revision also touched putty-wishlist]
2004-12-16 16:37:37 +00:00
return 1;
}
/*
* Print current directory. Easy as pie.
*/
int sftp_cmd_pwd(struct sftp_command *cmd)
{
Turn Backend into a sensible classoid. Nearly every part of the code that ever handles a full backend structure has historically done it using a pair of pointer variables, one pointing at a constant struct full of function pointers, and the other pointing to a 'void *' state object that's passed to each of those. While I'm modernising the rest of the code, this seems like a good time to turn that into the same more or less type-safe and less cumbersome system as I'm using for other parts of the code, such as Socket, Plug, BinaryPacketProtocol and so forth: the Backend structure contains a vtable pointer, and a system of macro wrappers handles dispatching through that vtable.
2018-09-11 15:23:38 +00:00
if (!backend) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
not_connected();
return 0;
Support for recursive file transfer in PSFTP. [originally from svn r4990] [this svn revision also touched putty-wishlist]
2004-12-16 16:37:37 +00:00
}
File transfer tools: sanitise remote filenames and stderr. This commit adds sanitisation to PSCP and PSFTP in the same style as I've just put it into Plink. This time, standard error is sanitised without reference to whether it's redirected (at least unless you give an override option), on the basis that where Plink is _sometimes_ an SSH transport for some other protocol, PSCP and PSFTP _always_ are. But also, the sanitiser is run over any remote filename sent by the server, substituting ? for any control characters it finds. That removes another avenue for the server to deliberately confuse the display. This commit fixes our bug 'pscp-unsanitised-server-output', aka the two notional 'vulnerabilities' CVE-2019-6109 and CVE-2019-6110. (Although we regard those in isolation as only bugs, not serious vulnerabilities, because their main threat was in hiding the evidence of a server having exploited other more serious vulns that we never had.)
2019-02-20 07:09:10 +00:00
with_stripctrl(san, pwd)
printf("Remote directory is %s\n", san);
Support for recursive file transfer in PSFTP. [originally from svn r4990] [this svn revision also touched putty-wishlist]
2004-12-16 16:37:37 +00:00
return 1;
}
/*
Implement mget and mput in PSFTP, supporting wildcards. [originally from svn r4991] [this svn revision also touched putty-wishlist]
2004-12-16 17:35:20 +00:00
* Get a file and save it at the local end. We have three very
* similar commands here. The basic one is `get'; `reget' differs
* in that it checks for the existence of the destination file and
* starts from where a previous aborted transfer left off; `mget'
* differs in that it interprets all its arguments as files to
* transfer (never as a different local name for a remote file) and
* can handle wildcards.
Support for recursive file transfer in PSFTP. [originally from svn r4990] [this svn revision also touched putty-wishlist]
2004-12-16 16:37:37 +00:00
*/
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
int sftp_general_get(struct sftp_command *cmd, bool restart, bool multiple)
Support for recursive file transfer in PSFTP. [originally from svn r4990] [this svn revision also touched putty-wishlist]
2004-12-16 16:37:37 +00:00
{
I've decided that trying to do wildcards in PSFTP as a special case of directory recursion was a strategic error: it obfuscates sftp_{get,put}_file(), and also it makes it very hard to handle subdirectory wildcards such as `foo/*'. Accordingly, here's a completely different approach, in which sftp_{get,put}_file() are still responsible for directory recursion, but wildcards are expanded in sftp_general_{get,put}() before being passed thereto. Subdirectory wildcards are now handled consistently across Unix, Windows and the remote server. [originally from svn r5045]
2004-12-30 13:51:37 +00:00
char *fname, *unwcfname, *origfname, *origwfname, *outfname;
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
int i, toret;
bool recurse = false;
Support for recursive file transfer in PSFTP. [originally from svn r4990] [this svn revision also touched putty-wishlist]
2004-12-16 16:37:37 +00:00
Turn Backend into a sensible classoid. Nearly every part of the code that ever handles a full backend structure has historically done it using a pair of pointer variables, one pointing at a constant struct full of function pointers, and the other pointing to a 'void *' state object that's passed to each of those. While I'm modernising the rest of the code, this seems like a good time to turn that into the same more or less type-safe and less cumbersome system as I'm using for other parts of the code, such as Socket, Plug, BinaryPacketProtocol and so forth: the Backend structure contains a vtable pointer, and a system of macro wrappers handles dispatching through that vtable.
2018-09-11 15:23:38 +00:00
if (!backend) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
not_connected();
return 0;
Support for recursive file transfer in PSFTP. [originally from svn r4990] [this svn revision also touched putty-wishlist]
2004-12-16 16:37:37 +00:00
}
i = 1;
while (i < cmd->nwords && cmd->words[i][0] == '-') {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
if (!strcmp(cmd->words[i], "--")) {
/* finish processing options */
i++;
break;
} else if (!strcmp(cmd->words[i], "-r")) {
recurse = true;
} else {
printf("%s: unrecognised option '%s'\n", cmd->words[0], cmd->words[i]);
return 0;
}
i++;
Support for recursive file transfer in PSFTP. [originally from svn r4990] [this svn revision also touched putty-wishlist]
2004-12-16 16:37:37 +00:00
}
if (i >= cmd->nwords) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
printf("%s: expects a filename\n", cmd->words[0]);
return 0;
Support for recursive file transfer in PSFTP. [originally from svn r4990] [this svn revision also touched putty-wishlist]
2004-12-16 16:37:37 +00:00
}
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
toret = 1;
Implement mget and mput in PSFTP, supporting wildcards. [originally from svn r4991] [this svn revision also touched putty-wishlist]
2004-12-16 17:35:20 +00:00
do {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
SftpWildcardMatcher *swcm;
origfname = cmd->words[i++];
unwcfname = snewn(strlen(origfname)+1, char);
if (multiple && !wc_unescape(unwcfname, origfname)) {
swcm = sftp_begin_wildcard_matching(origfname);
if (!swcm) {
sfree(unwcfname);
continue;
}
origwfname = sftp_wildcard_get_filename(swcm);
if (!origwfname) {
/* Politely warn the user that nothing matched. */
printf("%s: nothing matched\n", origfname);
sftp_finish_wildcard_matching(swcm);
sfree(unwcfname);
continue;
}
} else {
origwfname = origfname;
swcm = NULL;
}
while (origwfname) {
fname = canonify(origwfname);
if (!multiple && i < cmd->nwords)
outfname = cmd->words[i++];
else
outfname = stripslashes(origwfname, false);
toret = sftp_get_file(fname, outfname, recurse, restart);
sfree(fname);
if (swcm) {
sfree(origwfname);
origwfname = sftp_wildcard_get_filename(swcm);
} else {
origwfname = NULL;
}
}
sfree(unwcfname);
if (swcm)
sftp_finish_wildcard_matching(swcm);
if (!toret)
return toret;
Implement mget and mput in PSFTP, supporting wildcards. [originally from svn r4991] [this svn revision also touched putty-wishlist]
2004-12-16 17:35:20 +00:00
} while (multiple && i < cmd->nwords);
Support for recursive file transfer in PSFTP. [originally from svn r4990] [this svn revision also touched putty-wishlist]
2004-12-16 16:37:37 +00:00
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
return toret;
Support for recursive file transfer in PSFTP. [originally from svn r4990] [this svn revision also touched putty-wishlist]
2004-12-16 16:37:37 +00:00
}
int sftp_cmd_get(struct sftp_command *cmd)
{
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
return sftp_general_get(cmd, false, false);
Implement mget and mput in PSFTP, supporting wildcards. [originally from svn r4991] [this svn revision also touched putty-wishlist]
2004-12-16 17:35:20 +00:00
}
int sftp_cmd_mget(struct sftp_command *cmd)
{
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
return sftp_general_get(cmd, false, true);
Support for recursive file transfer in PSFTP. [originally from svn r4990] [this svn revision also touched putty-wishlist]
2004-12-16 16:37:37 +00:00
}
int sftp_cmd_reget(struct sftp_command *cmd)
{
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
return sftp_general_get(cmd, true, false);
Support for recursive file transfer in PSFTP. [originally from svn r4990] [this svn revision also touched putty-wishlist]
2004-12-16 16:37:37 +00:00
}
/*
Implement mget and mput in PSFTP, supporting wildcards. [originally from svn r4991] [this svn revision also touched putty-wishlist]
2004-12-16 17:35:20 +00:00
* Send a file and store it at the remote end. We have three very
* similar commands here. The basic one is `put'; `reput' differs
* in that it checks for the existence of the destination file and
* starts from where a previous aborted transfer left off; `mput'
* differs in that it interprets all its arguments as files to
* transfer (never as a different remote name for a local file) and
* can handle wildcards.
Support for recursive file transfer in PSFTP. [originally from svn r4990] [this svn revision also touched putty-wishlist]
2004-12-16 16:37:37 +00:00
*/
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
int sftp_general_put(struct sftp_command *cmd, bool restart, bool multiple)
Support for recursive file transfer in PSFTP. [originally from svn r4990] [this svn revision also touched putty-wishlist]
2004-12-16 16:37:37 +00:00
{
I've decided that trying to do wildcards in PSFTP as a special case of directory recursion was a strategic error: it obfuscates sftp_{get,put}_file(), and also it makes it very hard to handle subdirectory wildcards such as `foo/*'. Accordingly, here's a completely different approach, in which sftp_{get,put}_file() are still responsible for directory recursion, but wildcards are expanded in sftp_general_{get,put}() before being passed thereto. Subdirectory wildcards are now handled consistently across Unix, Windows and the remote server. [originally from svn r5045]
2004-12-30 13:51:37 +00:00
char *fname, *wfname, *origoutfname, *outfname;
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
int i;
int toret;
bool recurse = false;
Support for recursive file transfer in PSFTP. [originally from svn r4990] [this svn revision also touched putty-wishlist]
2004-12-16 16:37:37 +00:00
Turn Backend into a sensible classoid. Nearly every part of the code that ever handles a full backend structure has historically done it using a pair of pointer variables, one pointing at a constant struct full of function pointers, and the other pointing to a 'void *' state object that's passed to each of those. While I'm modernising the rest of the code, this seems like a good time to turn that into the same more or less type-safe and less cumbersome system as I'm using for other parts of the code, such as Socket, Plug, BinaryPacketProtocol and so forth: the Backend structure contains a vtable pointer, and a system of macro wrappers handles dispatching through that vtable.
2018-09-11 15:23:38 +00:00
if (!backend) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
not_connected();
return 0;
Support for recursive file transfer in PSFTP. [originally from svn r4990] [this svn revision also touched putty-wishlist]
2004-12-16 16:37:37 +00:00
}
i = 1;
while (i < cmd->nwords && cmd->words[i][0] == '-') {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
if (!strcmp(cmd->words[i], "--")) {
/* finish processing options */
i++;
break;
} else if (!strcmp(cmd->words[i], "-r")) {
recurse = true;
} else {
printf("%s: unrecognised option '%s'\n", cmd->words[0], cmd->words[i]);
return 0;
}
i++;
Support for recursive file transfer in PSFTP. [originally from svn r4990] [this svn revision also touched putty-wishlist]
2004-12-16 16:37:37 +00:00
}
if (i >= cmd->nwords) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
printf("%s: expects a filename\n", cmd->words[0]);
return 0;
Support for recursive file transfer in PSFTP. [originally from svn r4990] [this svn revision also touched putty-wishlist]
2004-12-16 16:37:37 +00:00
}
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
toret = 1;
Implement mget and mput in PSFTP, supporting wildcards. [originally from svn r4991] [this svn revision also touched putty-wishlist]
2004-12-16 17:35:20 +00:00
do {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
WildcardMatcher *wcm;
fname = cmd->words[i++];
if (multiple && test_wildcard(fname, false) == WCTYPE_WILDCARD) {
wcm = begin_wildcard_matching(fname);
wfname = wildcard_get_filename(wcm);
if (!wfname) {
/* Politely warn the user that nothing matched. */
printf("%s: nothing matched\n", fname);
finish_wildcard_matching(wcm);
continue;
}
} else {
wfname = fname;
wcm = NULL;
}
while (wfname) {
if (!multiple && i < cmd->nwords)
origoutfname = cmd->words[i++];
else
origoutfname = stripslashes(wfname, true);
outfname = canonify(origoutfname);
toret = sftp_put_file(wfname, outfname, recurse, restart);
sfree(outfname);
if (wcm) {
sfree(wfname);
wfname = wildcard_get_filename(wcm);
} else {
wfname = NULL;
}
}
if (wcm)
finish_wildcard_matching(wcm);
if (!toret)
return toret;
Support for recursive file transfer in PSFTP. [originally from svn r4990] [this svn revision also touched putty-wishlist]
2004-12-16 16:37:37 +00:00
Implement mget and mput in PSFTP, supporting wildcards. [originally from svn r4991] [this svn revision also touched putty-wishlist]
2004-12-16 17:35:20 +00:00
} while (multiple && i < cmd->nwords);
First stab at an SFTP client. Currently a Unixland testing app, not integrated into PuTTY. [originally from svn r938]
2001-02-23 18:21:44 +00:00
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
return toret;
First stab at an SFTP client. Currently a Unixland testing app, not integrated into PuTTY. [originally from svn r938]
2001-02-23 18:21:44 +00:00
}
More upgrades to psftp: it now supports mv, chmod, reget and reput. [originally from svn r1203]
2001-08-26 11:35:11 +00:00
int sftp_cmd_put(struct sftp_command *cmd)
{
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
return sftp_general_put(cmd, false, false);
Implement mget and mput in PSFTP, supporting wildcards. [originally from svn r4991] [this svn revision also touched putty-wishlist]
2004-12-16 17:35:20 +00:00
}
int sftp_cmd_mput(struct sftp_command *cmd)
{
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
return sftp_general_put(cmd, false, true);
More upgrades to psftp: it now supports mv, chmod, reget and reput. [originally from svn r1203]
2001-08-26 11:35:11 +00:00
}
int sftp_cmd_reput(struct sftp_command *cmd)
{
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
return sftp_general_put(cmd, true, false);
More upgrades to psftp: it now supports mv, chmod, reget and reput. [originally from svn r1203]
2001-08-26 11:35:11 +00:00
}
First stab at an SFTP client. Currently a Unixland testing app, not integrated into PuTTY. [originally from svn r938]
2001-02-23 18:21:44 +00:00
Patch to PSFTP: implement mkdir, rmdir, rm and scripting. Still to do: wildcards, chmod, mv, probably other things. [originally from svn r1168]
2001-08-04 14:19:51 +00:00
int sftp_cmd_mkdir(struct sftp_command *cmd)
{
char *dir;
First phase of SFTP re-engineering. Each base-level fxp_* function has been split into a send half and a receive half, so that callers can set several requests in motion at a time and deal with the responses in whatever order they arrive. [originally from svn r3318]
2003-06-29 14:26:09 +00:00
struct sftp_packet *pktin;
Clean up handling of the return value from sftp_find_request. In many places we simply enforce by assertion that it will match the request we sent out a moment ago: in fact it can also return NULL, so it makes more sense to report a proper error message if it doesn't return the expected value, and while we're at it, have that error message whatever message was helpfully left in fxp_error() by sftp_find_request when it failed. To do this, I've written a centralised function in psftp.c called sftp_wait_for_reply, which is handed a request that's just been sent out and deals with the mechanics of waiting for its reply, returning the reply when it arrives, and aborting with a sensible error if anything else arrives instead. The numerous sites in psftp.c which called sftp_find_request have all been rewritten to do this instead, and as a side effect they now look more sensible. The only other uses of sftp_find_request were in xfer_*load_gotpkt, which had to be tweaked in its own way. While I'm here, also fix memory management in sftp_find_request, which was freeing its input packet on some but not all error return paths. [originally from svn r9894]
2013-07-06 20:43:21 +00:00
struct sftp_request *req;
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
bool result;
"Nirwana Nirwana" points out that mget, mput and ls are not the only PSFTP commands that can make good use of wildcards! Now implemented wildcard support in rmdir, rm, mv and chmod. [originally from svn r5055]
2005-01-01 12:34:32 +00:00
int i, ret;
Patch to PSFTP: implement mkdir, rmdir, rm and scripting. Still to do: wildcards, chmod, mv, probably other things. [originally from svn r1168]
2001-08-04 14:19:51 +00:00
Turn Backend into a sensible classoid. Nearly every part of the code that ever handles a full backend structure has historically done it using a pair of pointer variables, one pointing at a constant struct full of function pointers, and the other pointing to a 'void *' state object that's passed to each of those. While I'm modernising the rest of the code, this seems like a good time to turn that into the same more or less type-safe and less cumbersome system as I'm using for other parts of the code, such as Socket, Plug, BinaryPacketProtocol and so forth: the Backend structure contains a vtable pointer, and a system of macro wrappers handles dispatching through that vtable.
2018-09-11 15:23:38 +00:00
if (!backend) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
not_connected();
return 0;
Allow PSFTP to be run with no arguments, in which case it enters the command-line state but all commands are disallowed except `open host.name'. The idea is to provide marginal extra niceness for people who double-click the icon without realising it's a cmdline app. [originally from svn r1480]
2001-12-13 18:42:34 +00:00
}
Patch to PSFTP: implement mkdir, rmdir, rm and scripting. Still to do: wildcards, chmod, mv, probably other things. [originally from svn r1168]
2001-08-04 14:19:51 +00:00
if (cmd->nwords < 2) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
printf("mkdir: expects a directory\n");
return 0;
Patch to PSFTP: implement mkdir, rmdir, rm and scripting. Still to do: wildcards, chmod, mv, probably other things. [originally from svn r1168]
2001-08-04 14:19:51 +00:00
}
"Nirwana Nirwana" points out that mget, mput and ls are not the only PSFTP commands that can make good use of wildcards! Now implemented wildcard support in rmdir, rm, mv and chmod. [originally from svn r5055]
2005-01-01 12:34:32 +00:00
ret = 1;
for (i = 1; i < cmd->nwords; i++) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
dir = canonify(cmd->words[i]);
"Nirwana Nirwana" points out that mget, mput and ls are not the only PSFTP commands that can make good use of wildcards! Now implemented wildcard support in rmdir, rm, mv and chmod. [originally from svn r5055]
2005-01-01 12:34:32 +00:00
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
req = fxp_mkdir_send(dir, NULL);
Clean up handling of the return value from sftp_find_request. In many places we simply enforce by assertion that it will match the request we sent out a moment ago: in fact it can also return NULL, so it makes more sense to report a proper error message if it doesn't return the expected value, and while we're at it, have that error message whatever message was helpfully left in fxp_error() by sftp_find_request when it failed. To do this, I've written a centralised function in psftp.c called sftp_wait_for_reply, which is handed a request that's just been sent out and deals with the mechanics of waiting for its reply, returning the reply when it arrives, and aborting with a sensible error if anything else arrives instead. The numerous sites in psftp.c which called sftp_find_request have all been rewritten to do this instead, and as a side effect they now look more sensible. The only other uses of sftp_find_request were in xfer_*load_gotpkt, which had to be tweaked in its own way. While I'm here, also fix memory management in sftp_find_request, which was freeing its input packet on some but not all error return paths. [originally from svn r9894]
2013-07-06 20:43:21 +00:00
pktin = sftp_wait_for_reply(req);
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
result = fxp_mkdir_recv(pktin, req);
"Nirwana Nirwana" points out that mget, mput and ls are not the only PSFTP commands that can make good use of wildcards! Now implemented wildcard support in rmdir, rm, mv and chmod. [originally from svn r5055]
2005-01-01 12:34:32 +00:00
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
if (!result) {
File transfer tools: sanitise remote filenames and stderr. This commit adds sanitisation to PSCP and PSFTP in the same style as I've just put it into Plink. This time, standard error is sanitised without reference to whether it's redirected (at least unless you give an override option), on the basis that where Plink is _sometimes_ an SSH transport for some other protocol, PSCP and PSFTP _always_ are. But also, the sanitiser is run over any remote filename sent by the server, substituting ? for any control characters it finds. That removes another avenue for the server to deliberately confuse the display. This commit fixes our bug 'pscp-unsanitised-server-output', aka the two notional 'vulnerabilities' CVE-2019-6109 and CVE-2019-6110. (Although we regard those in isolation as only bugs, not serious vulnerabilities, because their main threat was in hiding the evidence of a server having exploited other more serious vulns that we never had.)
2019-02-20 07:09:10 +00:00
with_stripctrl(san, dir)
printf("mkdir %s: %s\n", san, fxp_error());
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
ret = 0;
} else
File transfer tools: sanitise remote filenames and stderr. This commit adds sanitisation to PSCP and PSFTP in the same style as I've just put it into Plink. This time, standard error is sanitised without reference to whether it's redirected (at least unless you give an override option), on the basis that where Plink is _sometimes_ an SSH transport for some other protocol, PSCP and PSFTP _always_ are. But also, the sanitiser is run over any remote filename sent by the server, substituting ? for any control characters it finds. That removes another avenue for the server to deliberately confuse the display. This commit fixes our bug 'pscp-unsanitised-server-output', aka the two notional 'vulnerabilities' CVE-2019-6109 and CVE-2019-6110. (Although we regard those in isolation as only bugs, not serious vulnerabilities, because their main threat was in hiding the evidence of a server having exploited other more serious vulns that we never had.)
2019-02-20 07:09:10 +00:00
with_stripctrl(san, dir)
printf("mkdir %s: OK\n", san);
"Nirwana Nirwana" points out that mget, mput and ls are not the only PSFTP commands that can make good use of wildcards! Now implemented wildcard support in rmdir, rm, mv and chmod. [originally from svn r5055]
2005-01-01 12:34:32 +00:00
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
sfree(dir);
Patch to PSFTP: implement mkdir, rmdir, rm and scripting. Still to do: wildcards, chmod, mv, probably other things. [originally from svn r1168]
2001-08-04 14:19:51 +00:00
}
"Nirwana Nirwana" points out that mget, mput and ls are not the only PSFTP commands that can make good use of wildcards! Now implemented wildcard support in rmdir, rm, mv and chmod. [originally from svn r5055]
2005-01-01 12:34:32 +00:00
return ret;
}
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
static bool sftp_action_rmdir(void *vctx, char *dir)
"Nirwana Nirwana" points out that mget, mput and ls are not the only PSFTP commands that can make good use of wildcards! Now implemented wildcard support in rmdir, rm, mv and chmod. [originally from svn r5055]
2005-01-01 12:34:32 +00:00
{
struct sftp_packet *pktin;
Clean up handling of the return value from sftp_find_request. In many places we simply enforce by assertion that it will match the request we sent out a moment ago: in fact it can also return NULL, so it makes more sense to report a proper error message if it doesn't return the expected value, and while we're at it, have that error message whatever message was helpfully left in fxp_error() by sftp_find_request when it failed. To do this, I've written a centralised function in psftp.c called sftp_wait_for_reply, which is handed a request that's just been sent out and deals with the mechanics of waiting for its reply, returning the reply when it arrives, and aborting with a sensible error if anything else arrives instead. The numerous sites in psftp.c which called sftp_find_request have all been rewritten to do this instead, and as a side effect they now look more sensible. The only other uses of sftp_find_request were in xfer_*load_gotpkt, which had to be tweaked in its own way. While I'm here, also fix memory management in sftp_find_request, which was freeing its input packet on some but not all error return paths. [originally from svn r9894]
2013-07-06 20:43:21 +00:00
struct sftp_request *req;
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
bool result;
"Nirwana Nirwana" points out that mget, mput and ls are not the only PSFTP commands that can make good use of wildcards! Now implemented wildcard support in rmdir, rm, mv and chmod. [originally from svn r5055]
2005-01-01 12:34:32 +00:00
Clean up handling of the return value from sftp_find_request. In many places we simply enforce by assertion that it will match the request we sent out a moment ago: in fact it can also return NULL, so it makes more sense to report a proper error message if it doesn't return the expected value, and while we're at it, have that error message whatever message was helpfully left in fxp_error() by sftp_find_request when it failed. To do this, I've written a centralised function in psftp.c called sftp_wait_for_reply, which is handed a request that's just been sent out and deals with the mechanics of waiting for its reply, returning the reply when it arrives, and aborting with a sensible error if anything else arrives instead. The numerous sites in psftp.c which called sftp_find_request have all been rewritten to do this instead, and as a side effect they now look more sensible. The only other uses of sftp_find_request were in xfer_*load_gotpkt, which had to be tweaked in its own way. While I'm here, also fix memory management in sftp_find_request, which was freeing its input packet on some but not all error return paths. [originally from svn r9894]
2013-07-06 20:43:21 +00:00
req = fxp_rmdir_send(dir);
pktin = sftp_wait_for_reply(req);
result = fxp_rmdir_recv(pktin, req);
First phase of SFTP re-engineering. Each base-level fxp_* function has been split into a send half and a receive half, so that callers can set several requests in motion at a time and deal with the responses in whatever order they arrive. [originally from svn r3318]
2003-06-29 14:26:09 +00:00
Patch to PSFTP: implement mkdir, rmdir, rm and scripting. Still to do: wildcards, chmod, mv, probably other things. [originally from svn r1168]
2001-08-04 14:19:51 +00:00
if (!result) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
printf("rmdir %s: %s\n", dir, fxp_error());
return false;
Patch to PSFTP: implement mkdir, rmdir, rm and scripting. Still to do: wildcards, chmod, mv, probably other things. [originally from svn r1168]
2001-08-04 14:19:51 +00:00
}
Now that rm, mkdir, and rmdir can operate on lots of files, make them more chatty like the other multiple-file commands. [originally from svn r5059]
2005-01-01 16:35:57 +00:00
printf("rmdir %s: OK\n", dir);
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
return true;
Patch to PSFTP: implement mkdir, rmdir, rm and scripting. Still to do: wildcards, chmod, mv, probably other things. [originally from svn r1168]
2001-08-04 14:19:51 +00:00
}
int sftp_cmd_rmdir(struct sftp_command *cmd)
{
"Nirwana Nirwana" points out that mget, mput and ls are not the only PSFTP commands that can make good use of wildcards! Now implemented wildcard support in rmdir, rm, mv and chmod. [originally from svn r5055]
2005-01-01 12:34:32 +00:00
int i, ret;
Patch to PSFTP: implement mkdir, rmdir, rm and scripting. Still to do: wildcards, chmod, mv, probably other things. [originally from svn r1168]
2001-08-04 14:19:51 +00:00
Turn Backend into a sensible classoid. Nearly every part of the code that ever handles a full backend structure has historically done it using a pair of pointer variables, one pointing at a constant struct full of function pointers, and the other pointing to a 'void *' state object that's passed to each of those. While I'm modernising the rest of the code, this seems like a good time to turn that into the same more or less type-safe and less cumbersome system as I'm using for other parts of the code, such as Socket, Plug, BinaryPacketProtocol and so forth: the Backend structure contains a vtable pointer, and a system of macro wrappers handles dispatching through that vtable.
2018-09-11 15:23:38 +00:00
if (!backend) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
not_connected();
return 0;
Allow PSFTP to be run with no arguments, in which case it enters the command-line state but all commands are disallowed except `open host.name'. The idea is to provide marginal extra niceness for people who double-click the icon without realising it's a cmdline app. [originally from svn r1480]
2001-12-13 18:42:34 +00:00
}
Patch to PSFTP: implement mkdir, rmdir, rm and scripting. Still to do: wildcards, chmod, mv, probably other things. [originally from svn r1168]
2001-08-04 14:19:51 +00:00
if (cmd->nwords < 2) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
printf("rmdir: expects a directory\n");
return 0;
Patch to PSFTP: implement mkdir, rmdir, rm and scripting. Still to do: wildcards, chmod, mv, probably other things. [originally from svn r1168]
2001-08-04 14:19:51 +00:00
}
"Nirwana Nirwana" points out that mget, mput and ls are not the only PSFTP commands that can make good use of wildcards! Now implemented wildcard support in rmdir, rm, mv and chmod. [originally from svn r5055]
2005-01-01 12:34:32 +00:00
ret = 1;
for (i = 1; i < cmd->nwords; i++)
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
ret &= wildcard_iterate(cmd->words[i], sftp_action_rmdir, NULL);
Patch to PSFTP: implement mkdir, rmdir, rm and scripting. Still to do: wildcards, chmod, mv, probably other things. [originally from svn r1168]
2001-08-04 14:19:51 +00:00
"Nirwana Nirwana" points out that mget, mput and ls are not the only PSFTP commands that can make good use of wildcards! Now implemented wildcard support in rmdir, rm, mv and chmod. [originally from svn r5055]
2005-01-01 12:34:32 +00:00
return ret;
}
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
static bool sftp_action_rm(void *vctx, char *fname)
"Nirwana Nirwana" points out that mget, mput and ls are not the only PSFTP commands that can make good use of wildcards! Now implemented wildcard support in rmdir, rm, mv and chmod. [originally from svn r5055]
2005-01-01 12:34:32 +00:00
{
struct sftp_packet *pktin;
Clean up handling of the return value from sftp_find_request. In many places we simply enforce by assertion that it will match the request we sent out a moment ago: in fact it can also return NULL, so it makes more sense to report a proper error message if it doesn't return the expected value, and while we're at it, have that error message whatever message was helpfully left in fxp_error() by sftp_find_request when it failed. To do this, I've written a centralised function in psftp.c called sftp_wait_for_reply, which is handed a request that's just been sent out and deals with the mechanics of waiting for its reply, returning the reply when it arrives, and aborting with a sensible error if anything else arrives instead. The numerous sites in psftp.c which called sftp_find_request have all been rewritten to do this instead, and as a side effect they now look more sensible. The only other uses of sftp_find_request were in xfer_*load_gotpkt, which had to be tweaked in its own way. While I'm here, also fix memory management in sftp_find_request, which was freeing its input packet on some but not all error return paths. [originally from svn r9894]
2013-07-06 20:43:21 +00:00
struct sftp_request *req;
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
bool result;
"Nirwana Nirwana" points out that mget, mput and ls are not the only PSFTP commands that can make good use of wildcards! Now implemented wildcard support in rmdir, rm, mv and chmod. [originally from svn r5055]
2005-01-01 12:34:32 +00:00
Clean up handling of the return value from sftp_find_request. In many places we simply enforce by assertion that it will match the request we sent out a moment ago: in fact it can also return NULL, so it makes more sense to report a proper error message if it doesn't return the expected value, and while we're at it, have that error message whatever message was helpfully left in fxp_error() by sftp_find_request when it failed. To do this, I've written a centralised function in psftp.c called sftp_wait_for_reply, which is handed a request that's just been sent out and deals with the mechanics of waiting for its reply, returning the reply when it arrives, and aborting with a sensible error if anything else arrives instead. The numerous sites in psftp.c which called sftp_find_request have all been rewritten to do this instead, and as a side effect they now look more sensible. The only other uses of sftp_find_request were in xfer_*load_gotpkt, which had to be tweaked in its own way. While I'm here, also fix memory management in sftp_find_request, which was freeing its input packet on some but not all error return paths. [originally from svn r9894]
2013-07-06 20:43:21 +00:00
req = fxp_remove_send(fname);
pktin = sftp_wait_for_reply(req);
result = fxp_remove_recv(pktin, req);
First phase of SFTP re-engineering. Each base-level fxp_* function has been split into a send half and a receive half, so that callers can set several requests in motion at a time and deal with the responses in whatever order they arrive. [originally from svn r3318]
2003-06-29 14:26:09 +00:00
Patch to PSFTP: implement mkdir, rmdir, rm and scripting. Still to do: wildcards, chmod, mv, probably other things. [originally from svn r1168]
2001-08-04 14:19:51 +00:00
if (!result) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
printf("rm %s: %s\n", fname, fxp_error());
return false;
Patch to PSFTP: implement mkdir, rmdir, rm and scripting. Still to do: wildcards, chmod, mv, probably other things. [originally from svn r1168]
2001-08-04 14:19:51 +00:00
}
Now that rm, mkdir, and rmdir can operate on lots of files, make them more chatty like the other multiple-file commands. [originally from svn r5059]
2005-01-01 16:35:57 +00:00
printf("rm %s: OK\n", fname);
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
return true;
Patch to PSFTP: implement mkdir, rmdir, rm and scripting. Still to do: wildcards, chmod, mv, probably other things. [originally from svn r1168]
2001-08-04 14:19:51 +00:00
}
int sftp_cmd_rm(struct sftp_command *cmd)
{
"Nirwana Nirwana" points out that mget, mput and ls are not the only PSFTP commands that can make good use of wildcards! Now implemented wildcard support in rmdir, rm, mv and chmod. [originally from svn r5055]
2005-01-01 12:34:32 +00:00
int i, ret;
Patch to PSFTP: implement mkdir, rmdir, rm and scripting. Still to do: wildcards, chmod, mv, probably other things. [originally from svn r1168]
2001-08-04 14:19:51 +00:00
Turn Backend into a sensible classoid. Nearly every part of the code that ever handles a full backend structure has historically done it using a pair of pointer variables, one pointing at a constant struct full of function pointers, and the other pointing to a 'void *' state object that's passed to each of those. While I'm modernising the rest of the code, this seems like a good time to turn that into the same more or less type-safe and less cumbersome system as I'm using for other parts of the code, such as Socket, Plug, BinaryPacketProtocol and so forth: the Backend structure contains a vtable pointer, and a system of macro wrappers handles dispatching through that vtable.
2018-09-11 15:23:38 +00:00
if (!backend) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
not_connected();
return 0;
Allow PSFTP to be run with no arguments, in which case it enters the command-line state but all commands are disallowed except `open host.name'. The idea is to provide marginal extra niceness for people who double-click the icon without realising it's a cmdline app. [originally from svn r1480]
2001-12-13 18:42:34 +00:00
}
Patch to PSFTP: implement mkdir, rmdir, rm and scripting. Still to do: wildcards, chmod, mv, probably other things. [originally from svn r1168]
2001-08-04 14:19:51 +00:00
if (cmd->nwords < 2) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
printf("rm: expects a filename\n");
return 0;
Patch to PSFTP: implement mkdir, rmdir, rm and scripting. Still to do: wildcards, chmod, mv, probably other things. [originally from svn r1168]
2001-08-04 14:19:51 +00:00
}
"Nirwana Nirwana" points out that mget, mput and ls are not the only PSFTP commands that can make good use of wildcards! Now implemented wildcard support in rmdir, rm, mv and chmod. [originally from svn r5055]
2005-01-01 12:34:32 +00:00
ret = 1;
for (i = 1; i < cmd->nwords; i++)
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
ret &= wildcard_iterate(cmd->words[i], sftp_action_rm, NULL);
"Nirwana Nirwana" points out that mget, mput and ls are not the only PSFTP commands that can make good use of wildcards! Now implemented wildcard support in rmdir, rm, mv and chmod. [originally from svn r5055]
2005-01-01 12:34:32 +00:00
return ret;
}
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
static bool check_is_dir(char *dstfname)
"Nirwana Nirwana" points out that mget, mput and ls are not the only PSFTP commands that can make good use of wildcards! Now implemented wildcard support in rmdir, rm, mv and chmod. [originally from svn r5055]
2005-01-01 12:34:32 +00:00
{
struct sftp_packet *pktin;
Clean up handling of the return value from sftp_find_request. In many places we simply enforce by assertion that it will match the request we sent out a moment ago: in fact it can also return NULL, so it makes more sense to report a proper error message if it doesn't return the expected value, and while we're at it, have that error message whatever message was helpfully left in fxp_error() by sftp_find_request when it failed. To do this, I've written a centralised function in psftp.c called sftp_wait_for_reply, which is handed a request that's just been sent out and deals with the mechanics of waiting for its reply, returning the reply when it arrives, and aborting with a sensible error if anything else arrives instead. The numerous sites in psftp.c which called sftp_find_request have all been rewritten to do this instead, and as a side effect they now look more sensible. The only other uses of sftp_find_request were in xfer_*load_gotpkt, which had to be tweaked in its own way. While I'm here, also fix memory management in sftp_find_request, which was freeing its input packet on some but not all error return paths. [originally from svn r9894]
2013-07-06 20:43:21 +00:00
struct sftp_request *req;
"Nirwana Nirwana" points out that mget, mput and ls are not the only PSFTP commands that can make good use of wildcards! Now implemented wildcard support in rmdir, rm, mv and chmod. [originally from svn r5055]
2005-01-01 12:34:32 +00:00
struct fxp_attrs attrs;
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
bool result;
"Nirwana Nirwana" points out that mget, mput and ls are not the only PSFTP commands that can make good use of wildcards! Now implemented wildcard support in rmdir, rm, mv and chmod. [originally from svn r5055]
2005-01-01 12:34:32 +00:00
Clean up handling of the return value from sftp_find_request. In many places we simply enforce by assertion that it will match the request we sent out a moment ago: in fact it can also return NULL, so it makes more sense to report a proper error message if it doesn't return the expected value, and while we're at it, have that error message whatever message was helpfully left in fxp_error() by sftp_find_request when it failed. To do this, I've written a centralised function in psftp.c called sftp_wait_for_reply, which is handed a request that's just been sent out and deals with the mechanics of waiting for its reply, returning the reply when it arrives, and aborting with a sensible error if anything else arrives instead. The numerous sites in psftp.c which called sftp_find_request have all been rewritten to do this instead, and as a side effect they now look more sensible. The only other uses of sftp_find_request were in xfer_*load_gotpkt, which had to be tweaked in its own way. While I'm here, also fix memory management in sftp_find_request, which was freeing its input packet on some but not all error return paths. [originally from svn r9894]
2013-07-06 20:43:21 +00:00
req = fxp_stat_send(dstfname);
pktin = sftp_wait_for_reply(req);
result = fxp_stat_recv(pktin, req, &attrs);
"Nirwana Nirwana" points out that mget, mput and ls are not the only PSFTP commands that can make good use of wildcards! Now implemented wildcard support in rmdir, rm, mv and chmod. [originally from svn r5055]
2005-01-01 12:34:32 +00:00
if (result &&
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
(attrs.flags & SSH_FILEXFER_ATTR_PERMISSIONS) &&
(attrs.permissions & 0040000))
return true;
"Nirwana Nirwana" points out that mget, mput and ls are not the only PSFTP commands that can make good use of wildcards! Now implemented wildcard support in rmdir, rm, mv and chmod. [originally from svn r5055]
2005-01-01 12:34:32 +00:00
else
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
return false;
"Nirwana Nirwana" points out that mget, mput and ls are not the only PSFTP commands that can make good use of wildcards! Now implemented wildcard support in rmdir, rm, mv and chmod. [originally from svn r5055]
2005-01-01 12:34:32 +00:00
}
struct sftp_context_mv {
char *dstfname;
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
bool dest_is_dir;
"Nirwana Nirwana" points out that mget, mput and ls are not the only PSFTP commands that can make good use of wildcards! Now implemented wildcard support in rmdir, rm, mv and chmod. [originally from svn r5055]
2005-01-01 12:34:32 +00:00
};
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
static bool sftp_action_mv(void *vctx, char *srcfname)
"Nirwana Nirwana" points out that mget, mput and ls are not the only PSFTP commands that can make good use of wildcards! Now implemented wildcard support in rmdir, rm, mv and chmod. [originally from svn r5055]
2005-01-01 12:34:32 +00:00
{
struct sftp_context_mv *ctx = (struct sftp_context_mv *)vctx;
struct sftp_packet *pktin;
Clean up handling of the return value from sftp_find_request. In many places we simply enforce by assertion that it will match the request we sent out a moment ago: in fact it can also return NULL, so it makes more sense to report a proper error message if it doesn't return the expected value, and while we're at it, have that error message whatever message was helpfully left in fxp_error() by sftp_find_request when it failed. To do this, I've written a centralised function in psftp.c called sftp_wait_for_reply, which is handed a request that's just been sent out and deals with the mechanics of waiting for its reply, returning the reply when it arrives, and aborting with a sensible error if anything else arrives instead. The numerous sites in psftp.c which called sftp_find_request have all been rewritten to do this instead, and as a side effect they now look more sensible. The only other uses of sftp_find_request were in xfer_*load_gotpkt, which had to be tweaked in its own way. While I'm here, also fix memory management in sftp_find_request, which was freeing its input packet on some but not all error return paths. [originally from svn r9894]
2013-07-06 20:43:21 +00:00
struct sftp_request *req;
"Nirwana Nirwana" points out that mget, mput and ls are not the only PSFTP commands that can make good use of wildcards! Now implemented wildcard support in rmdir, rm, mv and chmod. [originally from svn r5055]
2005-01-01 12:34:32 +00:00
const char *error;
char *finalfname, *newcanon = NULL;
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
bool toret, result;
"Nirwana Nirwana" points out that mget, mput and ls are not the only PSFTP commands that can make good use of wildcards! Now implemented wildcard support in rmdir, rm, mv and chmod. [originally from svn r5055]
2005-01-01 12:34:32 +00:00
if (ctx->dest_is_dir) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
char *p;
char *newname;
"Nirwana Nirwana" points out that mget, mput and ls are not the only PSFTP commands that can make good use of wildcards! Now implemented wildcard support in rmdir, rm, mv and chmod. [originally from svn r5055]
2005-01-01 12:34:32 +00:00
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
p = srcfname + strlen(srcfname);
while (p > srcfname && p[-1] != '/') p--;
Make dupcat() into a variadic macro. Up until now, it's been a variadic _function_, whose argument list consists of 'const char *' ASCIZ strings to concatenate, terminated by one containing a null pointer. Now, that function is dupcat_fn(), and it's wrapped by a C99 variadic _macro_ called dupcat(), which automatically suffixes the null-pointer terminating argument. This has three benefits. Firstly, it's just less effort at every call site. Secondly, it protects against the risk of accidentally leaving off the NULL, causing arbitrary words of stack memory to be dereferenced as char pointers. And thirdly, it protects against the more subtle risk of writing a bare 'NULL' as the terminating argument, instead of casting it explicitly to a pointer. That last one is necessary because C permits the macro NULL to expand to an integer constant such as 0, so NULL by itself may not have pointer type, and worse, it may not be marshalled in a variadic argument list in the same way as a pointer. (For example, on a 64-bit machine it might only occupy 32 bits. And yet, on another 64-bit platform, it might work just fine, so that you don't notice the mistake!) I was inspired to do this by happening to notice one of those bare NULL terminators, and thinking I'd better check if there were any more. Turned out there were quite a few. Now there are none.
2019-10-14 18:42:37 +00:00
newname = dupcat(ctx->dstfname, "/", p);
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
newcanon = canonify(newname);
sfree(newname);
"Nirwana Nirwana" points out that mget, mput and ls are not the only PSFTP commands that can make good use of wildcards! Now implemented wildcard support in rmdir, rm, mv and chmod. [originally from svn r5055]
2005-01-01 12:34:32 +00:00
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
finalfname = newcanon;
"Nirwana Nirwana" points out that mget, mput and ls are not the only PSFTP commands that can make good use of wildcards! Now implemented wildcard support in rmdir, rm, mv and chmod. [originally from svn r5055]
2005-01-01 12:34:32 +00:00
} else {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
finalfname = ctx->dstfname;
Patch to PSFTP: implement mkdir, rmdir, rm and scripting. Still to do: wildcards, chmod, mv, probably other things. [originally from svn r1168]
2001-08-04 14:19:51 +00:00
}
Clean up handling of the return value from sftp_find_request. In many places we simply enforce by assertion that it will match the request we sent out a moment ago: in fact it can also return NULL, so it makes more sense to report a proper error message if it doesn't return the expected value, and while we're at it, have that error message whatever message was helpfully left in fxp_error() by sftp_find_request when it failed. To do this, I've written a centralised function in psftp.c called sftp_wait_for_reply, which is handed a request that's just been sent out and deals with the mechanics of waiting for its reply, returning the reply when it arrives, and aborting with a sensible error if anything else arrives instead. The numerous sites in psftp.c which called sftp_find_request have all been rewritten to do this instead, and as a side effect they now look more sensible. The only other uses of sftp_find_request were in xfer_*load_gotpkt, which had to be tweaked in its own way. While I'm here, also fix memory management in sftp_find_request, which was freeing its input packet on some but not all error return paths. [originally from svn r9894]
2013-07-06 20:43:21 +00:00
req = fxp_rename_send(srcfname, finalfname);
pktin = sftp_wait_for_reply(req);
result = fxp_rename_recv(pktin, req);
First phase of SFTP re-engineering. Each base-level fxp_* function has been split into a send half and a receive half, so that callers can set several requests in motion at a time and deal with the responses in whatever order they arrive. [originally from svn r3318]
2003-06-29 14:26:09 +00:00
"Nirwana Nirwana" points out that mget, mput and ls are not the only PSFTP commands that can make good use of wildcards! Now implemented wildcard support in rmdir, rm, mv and chmod. [originally from svn r5055]
2005-01-01 12:34:32 +00:00
error = result ? NULL : fxp_error();
if (error) {
File transfer tools: sanitise remote filenames and stderr. This commit adds sanitisation to PSCP and PSFTP in the same style as I've just put it into Plink. This time, standard error is sanitised without reference to whether it's redirected (at least unless you give an override option), on the basis that where Plink is _sometimes_ an SSH transport for some other protocol, PSCP and PSFTP _always_ are. But also, the sanitiser is run over any remote filename sent by the server, substituting ? for any control characters it finds. That removes another avenue for the server to deliberately confuse the display. This commit fixes our bug 'pscp-unsanitised-server-output', aka the two notional 'vulnerabilities' CVE-2019-6109 and CVE-2019-6110. (Although we regard those in isolation as only bugs, not serious vulnerabilities, because their main threat was in hiding the evidence of a server having exploited other more serious vulns that we never had.)
2019-02-20 07:09:10 +00:00
with_stripctrl(san, finalfname)
printf("mv %s %s: %s\n", srcfname, san, error);
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
toret = false;
"Nirwana Nirwana" points out that mget, mput and ls are not the only PSFTP commands that can make good use of wildcards! Now implemented wildcard support in rmdir, rm, mv and chmod. [originally from svn r5055]
2005-01-01 12:34:32 +00:00
} else {
File transfer tools: sanitise remote filenames and stderr. This commit adds sanitisation to PSCP and PSFTP in the same style as I've just put it into Plink. This time, standard error is sanitised without reference to whether it's redirected (at least unless you give an override option), on the basis that where Plink is _sometimes_ an SSH transport for some other protocol, PSCP and PSFTP _always_ are. But also, the sanitiser is run over any remote filename sent by the server, substituting ? for any control characters it finds. That removes another avenue for the server to deliberately confuse the display. This commit fixes our bug 'pscp-unsanitised-server-output', aka the two notional 'vulnerabilities' CVE-2019-6109 and CVE-2019-6110. (Although we regard those in isolation as only bugs, not serious vulnerabilities, because their main threat was in hiding the evidence of a server having exploited other more serious vulns that we never had.)
2019-02-20 07:09:10 +00:00
with_stripctrl(san, finalfname)
printf("%s -> %s\n", srcfname, san);
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
toret = true;
Patch to PSFTP: implement mkdir, rmdir, rm and scripting. Still to do: wildcards, chmod, mv, probably other things. [originally from svn r1168]
2001-08-04 14:19:51 +00:00
}
"Nirwana Nirwana" points out that mget, mput and ls are not the only PSFTP commands that can make good use of wildcards! Now implemented wildcard support in rmdir, rm, mv and chmod. [originally from svn r5055]
2005-01-01 12:34:32 +00:00
sfree(newcanon);
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
return toret;
More upgrades to psftp: it now supports mv, chmod, reget and reput. [originally from svn r1203]
2001-08-26 11:35:11 +00:00
}
int sftp_cmd_mv(struct sftp_command *cmd)
{
Refactor 'struct context *ctx = &actx' pattern. When I'm declaring a local instance of some context structure type to pass to a function which will pass it in turn to a callback, I've tended to use a declaration of the form struct context actx, *ctx = &actx; so that the outermost caller can initialise the context, and/or read out fields of it afterwards, by the same syntax 'ctx->foo' that the callback function will be using. So you get visual consistency between the two functions that share this context. It only just occurred to me that there's a much neater way to declare a context struct of this kind, which still makes 'ctx' behave like a pointer in the owning function, and doesn't need all that weird verbiage or a spare variable name: struct context ctx[1]; That's much nicer! I've switched to doing that in all existing cases I could find, and also in a couple of cases where I hadn't previously bothered to do the previous more cumbersome idiom.
2019-12-22 08:15:52 +00:00
struct sftp_context_mv ctx[1];
"Nirwana Nirwana" points out that mget, mput and ls are not the only PSFTP commands that can make good use of wildcards! Now implemented wildcard support in rmdir, rm, mv and chmod. [originally from svn r5055]
2005-01-01 12:34:32 +00:00
int i, ret;
More upgrades to psftp: it now supports mv, chmod, reget and reput. [originally from svn r1203]
2001-08-26 11:35:11 +00:00
Turn Backend into a sensible classoid. Nearly every part of the code that ever handles a full backend structure has historically done it using a pair of pointer variables, one pointing at a constant struct full of function pointers, and the other pointing to a 'void *' state object that's passed to each of those. While I'm modernising the rest of the code, this seems like a good time to turn that into the same more or less type-safe and less cumbersome system as I'm using for other parts of the code, such as Socket, Plug, BinaryPacketProtocol and so forth: the Backend structure contains a vtable pointer, and a system of macro wrappers handles dispatching through that vtable.
2018-09-11 15:23:38 +00:00
if (!backend) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
not_connected();
return 0;
Allow PSFTP to be run with no arguments, in which case it enters the command-line state but all commands are disallowed except `open host.name'. The idea is to provide marginal extra niceness for people who double-click the icon without realising it's a cmdline app. [originally from svn r1480]
2001-12-13 18:42:34 +00:00
}
More upgrades to psftp: it now supports mv, chmod, reget and reput. [originally from svn r1203]
2001-08-26 11:35:11 +00:00
if (cmd->nwords < 3) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
printf("mv: expects two filenames\n");
return 0;
More upgrades to psftp: it now supports mv, chmod, reget and reput. [originally from svn r1203]
2001-08-26 11:35:11 +00:00
}
"Nirwana Nirwana" points out that mget, mput and ls are not the only PSFTP commands that can make good use of wildcards! Now implemented wildcard support in rmdir, rm, mv and chmod. [originally from svn r5055]
2005-01-01 12:34:32 +00:00
ctx->dstfname = canonify(cmd->words[cmd->nwords-1]);
More upgrades to psftp: it now supports mv, chmod, reget and reput. [originally from svn r1203]
2001-08-26 11:35:11 +00:00
"Nirwana Nirwana" points out that mget, mput and ls are not the only PSFTP commands that can make good use of wildcards! Now implemented wildcard support in rmdir, rm, mv and chmod. [originally from svn r5055]
2005-01-01 12:34:32 +00:00
/*
* If there's more than one source argument, or one source
* argument which is a wildcard, we _require_ that the
* destination is a directory.
*/
ctx->dest_is_dir = check_is_dir(ctx->dstfname);
if ((cmd->nwords > 3 || is_wildcard(cmd->words[1])) && !ctx->dest_is_dir) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
printf("mv: multiple or wildcard arguments require the destination"
" to be a directory\n");
sfree(ctx->dstfname);
return 0;
More upgrades to psftp: it now supports mv, chmod, reget and reput. [originally from svn r1203]
2001-08-26 11:35:11 +00:00
}
Patch to PSFTP: implement mkdir, rmdir, rm and scripting. Still to do: wildcards, chmod, mv, probably other things. [originally from svn r1168]
2001-08-04 14:19:51 +00:00
"Nirwana Nirwana" points out that mget, mput and ls are not the only PSFTP commands that can make good use of wildcards! Now implemented wildcard support in rmdir, rm, mv and chmod. [originally from svn r5055]
2005-01-01 12:34:32 +00:00
/*
* Now iterate over the source arguments.
*/
ret = 1;
for (i = 1; i < cmd->nwords-1; i++)
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
ret &= wildcard_iterate(cmd->words[i], sftp_action_mv, ctx);
"Nirwana Nirwana" points out that mget, mput and ls are not the only PSFTP commands that can make good use of wildcards! Now implemented wildcard support in rmdir, rm, mv and chmod. [originally from svn r5055]
2005-01-01 12:34:32 +00:00
There's always one: fix small memory leak introduced in last revision. [originally from svn r5056]
2005-01-01 13:01:13 +00:00
sfree(ctx->dstfname);
"Nirwana Nirwana" points out that mget, mput and ls are not the only PSFTP commands that can make good use of wildcards! Now implemented wildcard support in rmdir, rm, mv and chmod. [originally from svn r5055]
2005-01-01 12:34:32 +00:00
return ret;
}
struct sftp_context_chmod {
unsigned attrs_clr, attrs_xor;
};
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
static bool sftp_action_chmod(void *vctx, char *fname)
"Nirwana Nirwana" points out that mget, mput and ls are not the only PSFTP commands that can make good use of wildcards! Now implemented wildcard support in rmdir, rm, mv and chmod. [originally from svn r5055]
2005-01-01 12:34:32 +00:00
{
struct fxp_attrs attrs;
struct sftp_packet *pktin;
Clean up handling of the return value from sftp_find_request. In many places we simply enforce by assertion that it will match the request we sent out a moment ago: in fact it can also return NULL, so it makes more sense to report a proper error message if it doesn't return the expected value, and while we're at it, have that error message whatever message was helpfully left in fxp_error() by sftp_find_request when it failed. To do this, I've written a centralised function in psftp.c called sftp_wait_for_reply, which is handed a request that's just been sent out and deals with the mechanics of waiting for its reply, returning the reply when it arrives, and aborting with a sensible error if anything else arrives instead. The numerous sites in psftp.c which called sftp_find_request have all been rewritten to do this instead, and as a side effect they now look more sensible. The only other uses of sftp_find_request were in xfer_*load_gotpkt, which had to be tweaked in its own way. While I'm here, also fix memory management in sftp_find_request, which was freeing its input packet on some but not all error return paths. [originally from svn r9894]
2013-07-06 20:43:21 +00:00
struct sftp_request *req;
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
bool result;
"Nirwana Nirwana" points out that mget, mput and ls are not the only PSFTP commands that can make good use of wildcards! Now implemented wildcard support in rmdir, rm, mv and chmod. [originally from svn r5055]
2005-01-01 12:34:32 +00:00
unsigned oldperms, newperms;
struct sftp_context_chmod *ctx = (struct sftp_context_chmod *)vctx;
Clean up handling of the return value from sftp_find_request. In many places we simply enforce by assertion that it will match the request we sent out a moment ago: in fact it can also return NULL, so it makes more sense to report a proper error message if it doesn't return the expected value, and while we're at it, have that error message whatever message was helpfully left in fxp_error() by sftp_find_request when it failed. To do this, I've written a centralised function in psftp.c called sftp_wait_for_reply, which is handed a request that's just been sent out and deals with the mechanics of waiting for its reply, returning the reply when it arrives, and aborting with a sensible error if anything else arrives instead. The numerous sites in psftp.c which called sftp_find_request have all been rewritten to do this instead, and as a side effect they now look more sensible. The only other uses of sftp_find_request were in xfer_*load_gotpkt, which had to be tweaked in its own way. While I'm here, also fix memory management in sftp_find_request, which was freeing its input packet on some but not all error return paths. [originally from svn r9894]
2013-07-06 20:43:21 +00:00
req = fxp_stat_send(fname);
pktin = sftp_wait_for_reply(req);
result = fxp_stat_recv(pktin, req, &attrs);
First phase of SFTP re-engineering. Each base-level fxp_* function has been split into a send half and a receive half, so that callers can set several requests in motion at a time and deal with the responses in whatever order they arrive. [originally from svn r3318]
2003-06-29 14:26:09 +00:00
"Nirwana Nirwana" points out that mget, mput and ls are not the only PSFTP commands that can make good use of wildcards! Now implemented wildcard support in rmdir, rm, mv and chmod. [originally from svn r5055]
2005-01-01 12:34:32 +00:00
if (!result || !(attrs.flags & SSH_FILEXFER_ATTR_PERMISSIONS)) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
printf("get attrs for %s: %s\n", fname,
result ? "file permissions not provided" : fxp_error());
return false;
"Nirwana Nirwana" points out that mget, mput and ls are not the only PSFTP commands that can make good use of wildcards! Now implemented wildcard support in rmdir, rm, mv and chmod. [originally from svn r5055]
2005-01-01 12:34:32 +00:00
}
More upgrades to psftp: it now supports mv, chmod, reget and reput. [originally from svn r1203]
2001-08-26 11:35:11 +00:00
"Nirwana Nirwana" points out that mget, mput and ls are not the only PSFTP commands that can make good use of wildcards! Now implemented wildcard support in rmdir, rm, mv and chmod. [originally from svn r5055]
2005-01-01 12:34:32 +00:00
attrs.flags = SSH_FILEXFER_ATTR_PERMISSIONS; /* perms _only_ */
oldperms = attrs.permissions & 07777;
attrs.permissions &= ~ctx->attrs_clr;
attrs.permissions ^= ctx->attrs_xor;
newperms = attrs.permissions & 07777;
First phase of SFTP re-engineering. Each base-level fxp_* function has been split into a send half and a receive half, so that callers can set several requests in motion at a time and deal with the responses in whatever order they arrive. [originally from svn r3318]
2003-06-29 14:26:09 +00:00
"Nirwana Nirwana" points out that mget, mput and ls are not the only PSFTP commands that can make good use of wildcards! Now implemented wildcard support in rmdir, rm, mv and chmod. [originally from svn r5055]
2005-01-01 12:34:32 +00:00
if (oldperms == newperms)
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
return true; /* no need to do anything! */
First phase of SFTP re-engineering. Each base-level fxp_* function has been split into a send half and a receive half, so that callers can set several requests in motion at a time and deal with the responses in whatever order they arrive. [originally from svn r3318]
2003-06-29 14:26:09 +00:00
Clean up handling of the return value from sftp_find_request. In many places we simply enforce by assertion that it will match the request we sent out a moment ago: in fact it can also return NULL, so it makes more sense to report a proper error message if it doesn't return the expected value, and while we're at it, have that error message whatever message was helpfully left in fxp_error() by sftp_find_request when it failed. To do this, I've written a centralised function in psftp.c called sftp_wait_for_reply, which is handed a request that's just been sent out and deals with the mechanics of waiting for its reply, returning the reply when it arrives, and aborting with a sensible error if anything else arrives instead. The numerous sites in psftp.c which called sftp_find_request have all been rewritten to do this instead, and as a side effect they now look more sensible. The only other uses of sftp_find_request were in xfer_*load_gotpkt, which had to be tweaked in its own way. While I'm here, also fix memory management in sftp_find_request, which was freeing its input packet on some but not all error return paths. [originally from svn r9894]
2013-07-06 20:43:21 +00:00
req = fxp_setstat_send(fname, attrs);
pktin = sftp_wait_for_reply(req);
result = fxp_setstat_recv(pktin, req);
First phase of SFTP re-engineering. Each base-level fxp_* function has been split into a send half and a receive half, so that callers can set several requests in motion at a time and deal with the responses in whatever order they arrive. [originally from svn r3318]
2003-06-29 14:26:09 +00:00
"Nirwana Nirwana" points out that mget, mput and ls are not the only PSFTP commands that can make good use of wildcards! Now implemented wildcard support in rmdir, rm, mv and chmod. [originally from svn r5055]
2005-01-01 12:34:32 +00:00
if (!result) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
printf("set attrs for %s: %s\n", fname, fxp_error());
return false;
More upgrades to psftp: it now supports mv, chmod, reget and reput. [originally from svn r1203]
2001-08-26 11:35:11 +00:00
}
"Nirwana Nirwana" points out that mget, mput and ls are not the only PSFTP commands that can make good use of wildcards! Now implemented wildcard support in rmdir, rm, mv and chmod. [originally from svn r5055]
2005-01-01 12:34:32 +00:00
printf("%s: %04o -> %04o\n", fname, oldperms, newperms);
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
return true;
Patch to PSFTP: implement mkdir, rmdir, rm and scripting. Still to do: wildcards, chmod, mv, probably other things. [originally from svn r1168]
2001-08-04 14:19:51 +00:00
}
More upgrades to psftp: it now supports mv, chmod, reget and reput. [originally from svn r1203]
2001-08-26 11:35:11 +00:00
int sftp_cmd_chmod(struct sftp_command *cmd)
{
"Nirwana Nirwana" points out that mget, mput and ls are not the only PSFTP commands that can make good use of wildcards! Now implemented wildcard support in rmdir, rm, mv and chmod. [originally from svn r5055]
2005-01-01 12:34:32 +00:00
char *mode;
int i, ret;
Refactor 'struct context *ctx = &actx' pattern. When I'm declaring a local instance of some context structure type to pass to a function which will pass it in turn to a callback, I've tended to use a declaration of the form struct context actx, *ctx = &actx; so that the outermost caller can initialise the context, and/or read out fields of it afterwards, by the same syntax 'ctx->foo' that the callback function will be using. So you get visual consistency between the two functions that share this context. It only just occurred to me that there's a much neater way to declare a context struct of this kind, which still makes 'ctx' behave like a pointer in the owning function, and doesn't need all that weird verbiage or a spare variable name: struct context ctx[1]; That's much nicer! I've switched to doing that in all existing cases I could find, and also in a couple of cases where I hadn't previously bothered to do the previous more cumbersome idiom.
2019-12-22 08:15:52 +00:00
struct sftp_context_chmod ctx[1];
More upgrades to psftp: it now supports mv, chmod, reget and reput. [originally from svn r1203]
2001-08-26 11:35:11 +00:00
Turn Backend into a sensible classoid. Nearly every part of the code that ever handles a full backend structure has historically done it using a pair of pointer variables, one pointing at a constant struct full of function pointers, and the other pointing to a 'void *' state object that's passed to each of those. While I'm modernising the rest of the code, this seems like a good time to turn that into the same more or less type-safe and less cumbersome system as I'm using for other parts of the code, such as Socket, Plug, BinaryPacketProtocol and so forth: the Backend structure contains a vtable pointer, and a system of macro wrappers handles dispatching through that vtable.
2018-09-11 15:23:38 +00:00
if (!backend) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
not_connected();
return 0;
Allow PSFTP to be run with no arguments, in which case it enters the command-line state but all commands are disallowed except `open host.name'. The idea is to provide marginal extra niceness for people who double-click the icon without realising it's a cmdline app. [originally from svn r1480]
2001-12-13 18:42:34 +00:00
}
More upgrades to psftp: it now supports mv, chmod, reget and reput. [originally from svn r1203]
2001-08-26 11:35:11 +00:00
if (cmd->nwords < 3) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
printf("chmod: expects a mode specifier and a filename\n");
return 0;
More upgrades to psftp: it now supports mv, chmod, reget and reput. [originally from svn r1203]
2001-08-26 11:35:11 +00:00
}
/*
* Attempt to parse the mode specifier in cmd->words[1]. We
* don't support the full horror of Unix chmod; instead we
* support a much simpler syntax in which the user can either
* specify an octal number, or a comma-separated sequence of
* [ugoa]*[-+=][rwxst]+. (The initial [ugoa] sequence may
* _only_ be omitted if the only attribute mentioned is t,
* since all others require a user/group/other specification.
* Additionally, the s attribute may not be specified for any
* [ugoa] specifications other than exactly u or exactly g.
*/
"Nirwana Nirwana" points out that mget, mput and ls are not the only PSFTP commands that can make good use of wildcards! Now implemented wildcard support in rmdir, rm, mv and chmod. [originally from svn r5055]
2005-01-01 12:34:32 +00:00
ctx->attrs_clr = ctx->attrs_xor = 0;
More upgrades to psftp: it now supports mv, chmod, reget and reput. [originally from svn r1203]
2001-08-26 11:35:11 +00:00
mode = cmd->words[1];
if (mode[0] >= '0' && mode[0] <= '9') {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
if (mode[strspn(mode, "01234567")]) {
printf("chmod: numeric file modes should"
" contain digits 0-7 only\n");
return 0;
}
ctx->attrs_clr = 07777;
sscanf(mode, "%o", &ctx->attrs_xor);
ctx->attrs_xor &= ctx->attrs_clr;
More upgrades to psftp: it now supports mv, chmod, reget and reput. [originally from svn r1203]
2001-08-26 11:35:11 +00:00
} else {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
while (*mode) {
char *modebegin = mode;
unsigned subset, perms;
int action;
subset = 0;
while (*mode && *mode != ',' &&
*mode != '+' && *mode != '-' && *mode != '=') {
switch (*mode) {
case 'u': subset |= 04700; break; /* setuid, user perms */
case 'g': subset |= 02070; break; /* setgid, group perms */
case 'o': subset |= 00007; break; /* just other perms */
case 'a': subset |= 06777; break; /* all of the above */
default:
printf("chmod: file mode '%.*s' contains unrecognised"
" user/group/other specifier '%c'\n",
(int)strcspn(modebegin, ","), modebegin, *mode);
return 0;
}
mode++;
}
if (!*mode || *mode == ',') {
printf("chmod: file mode '%.*s' is incomplete\n",
(int)strcspn(modebegin, ","), modebegin);
return 0;
}
action = *mode++;
if (!*mode || *mode == ',') {
printf("chmod: file mode '%.*s' is incomplete\n",
(int)strcspn(modebegin, ","), modebegin);
return 0;
}
perms = 0;
while (*mode && *mode != ',') {
switch (*mode) {
case 'r': perms |= 00444; break;
case 'w': perms |= 00222; break;
case 'x': perms |= 00111; break;
case 't': perms |= 01000; subset |= 01000; break;
case 's':
if ((subset & 06777) != 04700 &&
(subset & 06777) != 02070) {
printf("chmod: file mode '%.*s': set[ug]id bit should"
" be used with exactly one of u or g only\n",
(int)strcspn(modebegin, ","), modebegin);
return 0;
}
perms |= 06000;
break;
default:
printf("chmod: file mode '%.*s' contains unrecognised"
" permission specifier '%c'\n",
(int)strcspn(modebegin, ","), modebegin, *mode);
return 0;
}
mode++;
}
if (!(subset & 06777) && (perms &~ subset)) {
printf("chmod: file mode '%.*s' contains no user/group/other"
" specifier and permissions other than 't' \n",
(int)strcspn(modebegin, ","), modebegin);
return 0;
}
perms &= subset;
switch (action) {
case '+':
ctx->attrs_clr |= perms;
ctx->attrs_xor |= perms;
break;
case '-':
ctx->attrs_clr |= perms;
ctx->attrs_xor &= ~perms;
break;
case '=':
ctx->attrs_clr |= subset;
ctx->attrs_xor |= perms;
break;
}
if (*mode) mode++; /* eat comma */
}
More upgrades to psftp: it now supports mv, chmod, reget and reput. [originally from svn r1203]
2001-08-26 11:35:11 +00:00
}
"Nirwana Nirwana" points out that mget, mput and ls are not the only PSFTP commands that can make good use of wildcards! Now implemented wildcard support in rmdir, rm, mv and chmod. [originally from svn r5055]
2005-01-01 12:34:32 +00:00
ret = 1;
for (i = 2; i < cmd->nwords; i++)
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
ret &= wildcard_iterate(cmd->words[i], sftp_action_chmod, ctx);
More upgrades to psftp: it now supports mv, chmod, reget and reput. [originally from svn r1203]
2001-08-26 11:35:11 +00:00
"Nirwana Nirwana" points out that mget, mput and ls are not the only PSFTP commands that can make good use of wildcards! Now implemented wildcard support in rmdir, rm, mv and chmod. [originally from svn r5055]
2005-01-01 12:34:32 +00:00
return ret;
More upgrades to psftp: it now supports mv, chmod, reget and reput. [originally from svn r1203]
2001-08-26 11:35:11 +00:00
}
Patch to PSFTP: implement mkdir, rmdir, rm and scripting. Still to do: wildcards, chmod, mv, probably other things. [originally from svn r1168]
2001-08-04 14:19:51 +00:00
Allow PSFTP to be run with no arguments, in which case it enters the command-line state but all commands are disallowed except `open host.name'. The idea is to provide marginal extra niceness for people who double-click the icon without realising it's a cmdline app. [originally from svn r1480]
2001-12-13 18:42:34 +00:00
static int sftp_cmd_open(struct sftp_command *cmd)
{
Darryl L. Miles's patch to support an optional port number argument on the PSFTP `open' command; it was arguably a bug that this command couldn't do such an obvious thing that could be done from the main command line. Also had to fix a NULL-dereference in do_sftp_cleanup in the process. [originally from svn r3754]
2004-01-21 19:56:08 +00:00
int portnumber;
Turn Backend into a sensible classoid. Nearly every part of the code that ever handles a full backend structure has historically done it using a pair of pointer variables, one pointing at a constant struct full of function pointers, and the other pointing to a 'void *' state object that's passed to each of those. While I'm modernising the rest of the code, this seems like a good time to turn that into the same more or less type-safe and less cumbersome system as I'm using for other parts of the code, such as Socket, Plug, BinaryPacketProtocol and so forth: the Backend structure contains a vtable pointer, and a system of macro wrappers handles dispatching through that vtable.
2018-09-11 15:23:38 +00:00
if (backend) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
printf("psftp: already connected\n");
return 0;
Allow PSFTP to be run with no arguments, in which case it enters the command-line state but all commands are disallowed except `open host.name'. The idea is to provide marginal extra niceness for people who double-click the icon without realising it's a cmdline app. [originally from svn r1480]
2001-12-13 18:42:34 +00:00
}
if (cmd->nwords < 2) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
printf("open: expects a host name\n");
return 0;
Allow PSFTP to be run with no arguments, in which case it enters the command-line state but all commands are disallowed except `open host.name'. The idea is to provide marginal extra niceness for people who double-click the icon without realising it's a cmdline app. [originally from svn r1480]
2001-12-13 18:42:34 +00:00
}
Darryl L. Miles's patch to support an optional port number argument on the PSFTP `open' command; it was arguably a bug that this command couldn't do such an obvious thing that could be done from the main command line. Also had to fix a NULL-dereference in do_sftp_cleanup in the process. [originally from svn r3754]
2004-01-21 19:56:08 +00:00
if (cmd->nwords > 2) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
portnumber = atoi(cmd->words[2]);
if (portnumber == 0) {
printf("open: invalid port number\n");
return 0;
}
Darryl L. Miles's patch to support an optional port number argument on the PSFTP `open' command; it was arguably a bug that this command couldn't do such an obvious thing that could be done from the main command line. Also had to fix a NULL-dereference in do_sftp_cleanup in the process. [originally from svn r3754]
2004-01-21 19:56:08 +00:00
} else
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
portnumber = 0;
Darryl L. Miles's patch to support an optional port number argument on the PSFTP `open' command; it was arguably a bug that this command couldn't do such an obvious thing that could be done from the main command line. Also had to fix a NULL-dereference in do_sftp_cleanup in the process. [originally from svn r3754]
2004-01-21 19:56:08 +00:00
if (psftp_connect(cmd->words[1], NULL, portnumber)) {
Turn Backend into a sensible classoid. Nearly every part of the code that ever handles a full backend structure has historically done it using a pair of pointer variables, one pointing at a constant struct full of function pointers, and the other pointing to a 'void *' state object that's passed to each of those. While I'm modernising the rest of the code, this seems like a good time to turn that into the same more or less type-safe and less cumbersome system as I'm using for other parts of the code, such as Socket, Plug, BinaryPacketProtocol and so forth: the Backend structure contains a vtable pointer, and a system of macro wrappers handles dispatching through that vtable.
2018-09-11 15:23:38 +00:00
backend = NULL; /* connection is already closed */
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
return -1; /* this is fatal */
Allow PSFTP to be run with no arguments, in which case it enters the command-line state but all commands are disallowed except `open host.name'. The idea is to provide marginal extra niceness for people who double-click the icon without realising it's a cmdline app. [originally from svn r1480]
2001-12-13 18:42:34 +00:00
}
do_sftp_init();
Tidied up PSFTP batch mode. The gross hack using fxp_error_message to report command failures is now gone; instead each sftp_cmd_* routine returns 0 or 1 depending on success, like they should have done right from the start. This fixes problems with `ls' prematurely terminating PSFTP batch files. [originally from svn r1481]
2001-12-13 19:26:51 +00:00
return 1;
Allow PSFTP to be run with no arguments, in which case it enters the command-line state but all commands are disallowed except `open host.name'. The idea is to provide marginal extra niceness for people who double-click the icon without realising it's a cmdline app. [originally from svn r1480]
2001-12-13 18:42:34 +00:00
}
Add the `local' command set to PSFTP: lcd, lpwd, and ! to spawn a Windows command. [originally from svn r1501]
2001-12-16 13:33:04 +00:00
static int sftp_cmd_lcd(struct sftp_command *cmd)
{
Next phase of general SFTP reworking: psftp.c is now a platform- independent source file. All Windowsisms have been moved out to winsftp.c. [originally from svn r3418]
2003-08-24 12:47:46 +00:00
char *currdir, *errmsg;
Add the `local' command set to PSFTP: lcd, lpwd, and ! to spawn a Windows command. [originally from svn r1501]
2001-12-16 13:33:04 +00:00
if (cmd->nwords < 2) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
printf("lcd: expects a local directory name\n");
return 0;
Add the `local' command set to PSFTP: lcd, lpwd, and ! to spawn a Windows command. [originally from svn r1501]
2001-12-16 13:33:04 +00:00
}
Next phase of general SFTP reworking: psftp.c is now a platform- independent source file. All Windowsisms have been moved out to winsftp.c. [originally from svn r3418]
2003-08-24 12:47:46 +00:00
errmsg = psftp_lcd(cmd->words[1]);
if (errmsg) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
printf("lcd: unable to change directory: %s\n", errmsg);
sfree(errmsg);
return 0;
Add the `local' command set to PSFTP: lcd, lpwd, and ! to spawn a Windows command. [originally from svn r1501]
2001-12-16 13:33:04 +00:00
}
Next phase of general SFTP reworking: psftp.c is now a platform- independent source file. All Windowsisms have been moved out to winsftp.c. [originally from svn r3418]
2003-08-24 12:47:46 +00:00
currdir = psftp_getcwd();
Add the `local' command set to PSFTP: lcd, lpwd, and ! to spawn a Windows command. [originally from svn r1501]
2001-12-16 13:33:04 +00:00
printf("New local directory is %s\n", currdir);
sfree(currdir);
return 1;
}
static int sftp_cmd_lpwd(struct sftp_command *cmd)
{
char *currdir;
Next phase of general SFTP reworking: psftp.c is now a platform- independent source file. All Windowsisms have been moved out to winsftp.c. [originally from svn r3418]
2003-08-24 12:47:46 +00:00
currdir = psftp_getcwd();
Add the `local' command set to PSFTP: lcd, lpwd, and ! to spawn a Windows command. [originally from svn r1501]
2001-12-16 13:33:04 +00:00
printf("Current local directory is %s\n", currdir);
sfree(currdir);
return 1;
}
static int sftp_cmd_pling(struct sftp_command *cmd)
{
int exitcode;
exitcode = system(cmd->words[1]);
return (exitcode == 0);
}
Add online help in PSFTP. [originally from svn r1261]
2001-09-09 16:29:51 +00:00
static int sftp_cmd_help(struct sftp_command *cmd);
First stab at an SFTP client. Currently a Unixland testing app, not integrated into PuTTY. [originally from svn r938]
2001-02-23 18:21:44 +00:00
static struct sftp_cmd_lookup {
Giant const-correctness patch of doom! Having found a lot of unfixed constness issues in recent development, I thought perhaps it was time to get proactive, so I compiled the whole codebase with -Wwrite-strings. That turned up a huge load of const problems, which I've fixed in this commit: the Unix build now goes cleanly through with -Wwrite-strings, and the Windows build is as close as I could get it (there are some lingering issues due to occasional Windows API functions like AcquireCredentialsHandle not having the right constness). Notable fallout beyond the purely mechanical changing of types: - the stuff saved by cmdline_save_param() is now explicitly dupstr()ed, and freed in cmdline_run_saved. - I couldn't make both string arguments to cmdline_process_param() const, because it intentionally writes to one of them in the case where it's the argument to -pw (in the vain hope of being at least slightly friendly to 'ps'), so elsewhere I had to temporarily dupstr() something for the sake of passing it to that function - I had to invent a silly parallel version of const_cmp() so I could pass const string literals in to lookup functions. - stripslashes() in pscp.c and psftp.c has the annoying strchr nature
2015-05-15 10:15:42 +00:00
const char *name;
Add online help in PSFTP. [originally from svn r1261]
2001-09-09 16:29:51 +00:00
/*
* For help purposes, there are two kinds of command:
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
*
Add online help in PSFTP. [originally from svn r1261]
2001-09-09 16:29:51 +00:00
* - primary commands, in which `longhelp' is non-NULL. In
* this case `shorthelp' is descriptive text, and `longhelp'
* is longer descriptive text intended to be printed after
* the command name.
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
*
Add online help in PSFTP. [originally from svn r1261]
2001-09-09 16:29:51 +00:00
* - alias commands, in which `longhelp' is NULL. In this case
* `shorthelp' is the name of a primary command, which
* contains the help that should double up for this command.
*/
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
bool listed; /* do we list this in primary help? */
Giant const-correctness patch of doom! Having found a lot of unfixed constness issues in recent development, I thought perhaps it was time to get proactive, so I compiled the whole codebase with -Wwrite-strings. That turned up a huge load of const problems, which I've fixed in this commit: the Unix build now goes cleanly through with -Wwrite-strings, and the Windows build is as close as I could get it (there are some lingering issues due to occasional Windows API functions like AcquireCredentialsHandle not having the right constness). Notable fallout beyond the purely mechanical changing of types: - the stuff saved by cmdline_save_param() is now explicitly dupstr()ed, and freed in cmdline_run_saved. - I couldn't make both string arguments to cmdline_process_param() const, because it intentionally writes to one of them in the case where it's the argument to -pw (in the vain hope of being at least slightly friendly to 'ps'), so elsewhere I had to temporarily dupstr() something for the sake of passing it to that function - I had to invent a silly parallel version of const_cmp() so I could pass const string literals in to lookup functions. - stripslashes() in pscp.c and psftp.c has the annoying strchr nature
2015-05-15 10:15:42 +00:00
const char *shorthelp;
const char *longhelp;
Run entire source base through GNU indent to tidy up the varying coding styles of the various contributors! Woohoo! [originally from svn r1098]
2001-05-06 14:35:20 +00:00
int (*obey) (struct sftp_command *);
First stab at an SFTP client. Currently a Unixland testing app, not integrated into PuTTY. [originally from svn r938]
2001-02-23 18:21:44 +00:00
} sftp_lookup[] = {
/*
* List of sftp commands. This is binary-searched so it MUST be
* in ASCII order.
*/
Run entire source base through GNU indent to tidy up the varying coding styles of the various contributors! Woohoo! [originally from svn r1098]
2001-05-06 14:35:20 +00:00
{
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
"!", true, "run a local command",
"<command>\n"
/* FIXME: this example is crap for non-Windows. */
" Runs a local command. For example, \"!del myfile\".\n",
sftp_cmd_pling
Add the `local' command set to PSFTP: lcd, lpwd, and ! to spawn a Windows command. [originally from svn r1501]
2001-12-16 13:33:04 +00:00
},
{
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
"bye", true, "finish your SFTP session",
"\n"
" Terminates your SFTP session and quits the PSFTP program.\n",
sftp_cmd_quit
Add online help in PSFTP. [originally from svn r1261]
2001-09-09 16:29:51 +00:00
},
{
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
"cd", true, "change your remote working directory",
" [ <new working directory> ]\n"
" Change the remote working directory for your SFTP session.\n"
" If a new working directory is not supplied, you will be\n"
" returned to your home directory.\n",
sftp_cmd_cd
Add online help in PSFTP. [originally from svn r1261]
2001-09-09 16:29:51 +00:00
},
{
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
"chmod", true, "change file permissions and modes",
" <modes> <filename-or-wildcard> [ <filename-or-wildcard>... ]\n"
" Change the file permissions on one or more remote files or\n"
" directories.\n"
" <modes> can be any octal Unix permission specifier.\n"
" Alternatively, <modes> can include the following modifiers:\n"
" u+r make file readable by owning user\n"
" u+w make file writable by owning user\n"
" u+x make file executable by owning user\n"
" u-r make file not readable by owning user\n"
" [also u-w, u-x]\n"
" g+r make file readable by members of owning group\n"
" [also g+w, g+x, g-r, g-w, g-x]\n"
" o+r make file readable by all other users\n"
" [also o+w, o+x, o-r, o-w, o-x]\n"
" a+r make file readable by absolutely everybody\n"
" [also a+w, a+x, a-r, a-w, a-x]\n"
" u+s enable the Unix set-user-ID bit\n"
" u-s disable the Unix set-user-ID bit\n"
" g+s enable the Unix set-group-ID bit\n"
" g-s disable the Unix set-group-ID bit\n"
" +t enable the Unix \"sticky bit\"\n"
" You can give more than one modifier for the same user (\"g-rwx\"), and\n"
" more than one user for the same modifier (\"ug+w\"). You can\n"
" use commas to separate different modifiers (\"u+rwx,g+s\").\n",
sftp_cmd_chmod
Add online help in PSFTP. [originally from svn r1261]
2001-09-09 16:29:51 +00:00
},
Implement the `close' command, which terminates an SFTP session but does not quit PSFTP, so you can then issue another `open' to connect to somewhere else. This has apparently been trivial for some time, for exactly the same reasons that `reuse-windows' was so easy, but it hadn't occurred to me to actually do it until now. [originally from svn r4994]
2004-12-16 19:19:59 +00:00
{
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
"close", true, "finish your SFTP session but do not quit PSFTP",
"\n"
" Terminates your SFTP session, but does not quit the PSFTP\n"
" program. You can then use \"open\" to start another SFTP\n"
" session, to the same server or to a different one.\n",
sftp_cmd_close
Implement the `close' command, which terminates an SFTP session but does not quit PSFTP, so you can then issue another `open' to connect to somewhere else. This has apparently been trivial for some time, for exactly the same reasons that `reuse-windows' was so easy, but it hadn't occurred to me to actually do it until now. [originally from svn r4994]
2004-12-16 19:19:59 +00:00
},
Add online help in PSFTP. [originally from svn r1261]
2001-09-09 16:29:51 +00:00
{
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
"del", true, "delete files on the remote server",
" <filename-or-wildcard> [ <filename-or-wildcard>... ]\n"
" Delete a file or files from the server.\n",
sftp_cmd_rm
Add online help in PSFTP. [originally from svn r1261]
2001-09-09 16:29:51 +00:00
},
{
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
"delete", false, "del", NULL, sftp_cmd_rm
Add online help in PSFTP. [originally from svn r1261]
2001-09-09 16:29:51 +00:00
},
{
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
"dir", true, "list remote files",
" [ <directory-name> ]/[ <wildcard> ]\n"
" List the contents of a specified directory on the server.\n"
" If <directory-name> is not given, the current working directory\n"
" is assumed.\n"
" If <wildcard> is given, it is treated as a set of files to\n"
" list; otherwise, all files are listed.\n",
sftp_cmd_ls
Add online help in PSFTP. [originally from svn r1261]
2001-09-09 16:29:51 +00:00
},
{
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
"exit", true, "bye", NULL, sftp_cmd_quit
Add online help in PSFTP. [originally from svn r1261]
2001-09-09 16:29:51 +00:00
},
{
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
"get", true, "download a file from the server to your local machine",
" [ -r ] [ -- ] <filename> [ <local-filename> ]\n"
" Downloads a file on the server and stores it locally under\n"
" the same name, or under a different one if you supply the\n"
" argument <local-filename>.\n"
" If -r specified, recursively fetch a directory.\n",
sftp_cmd_get
Add online help in PSFTP. [originally from svn r1261]
2001-09-09 16:29:51 +00:00
},
{
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
"help", true, "give help",
" [ <command> [ <command> ... ] ]\n"
" Give general help if no commands are specified.\n"
" If one or more commands are specified, give specific help on\n"
" those particular commands.\n",
sftp_cmd_help
Add online help in PSFTP. [originally from svn r1261]
2001-09-09 16:29:51 +00:00
},
{
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
"lcd", true, "change local working directory",
" <local-directory-name>\n"
" Change the local working directory of the PSFTP program (the\n"
" default location where the \"get\" command will save files).\n",
sftp_cmd_lcd
Add the `local' command set to PSFTP: lcd, lpwd, and ! to spawn a Windows command. [originally from svn r1501]
2001-12-16 13:33:04 +00:00
},
{
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
"lpwd", true, "print local working directory",
"\n"
" Print the local working directory of the PSFTP program (the\n"
" default location where the \"get\" command will save files).\n",
sftp_cmd_lpwd
Add the `local' command set to PSFTP: lcd, lpwd, and ! to spawn a Windows command. [originally from svn r1501]
2001-12-16 13:33:04 +00:00
},
{
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
"ls", true, "dir", NULL,
sftp_cmd_ls
Add online help in PSFTP. [originally from svn r1261]
2001-09-09 16:29:51 +00:00
},
Implement mget and mput in PSFTP, supporting wildcards. [originally from svn r4991] [this svn revision also touched putty-wishlist]
2004-12-16 17:35:20 +00:00
{
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
"mget", true, "download multiple files at once",
" [ -r ] [ -- ] <filename-or-wildcard> [ <filename-or-wildcard>... ]\n"
" Downloads many files from the server, storing each one under\n"
" the same name it has on the server side. You can use wildcards\n"
" such as \"*.c\" to specify lots of files at once.\n"
" If -r specified, recursively fetch files and directories.\n",
sftp_cmd_mget
Implement mget and mput in PSFTP, supporting wildcards. [originally from svn r4991] [this svn revision also touched putty-wishlist]
2004-12-16 17:35:20 +00:00
},
Add online help in PSFTP. [originally from svn r1261]
2001-09-09 16:29:51 +00:00
{
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
"mkdir", true, "create directories on the remote server",
" <directory-name> [ <directory-name>... ]\n"
" Creates directories with the given names on the server.\n",
sftp_cmd_mkdir
Add online help in PSFTP. [originally from svn r1261]
2001-09-09 16:29:51 +00:00
},
Implement mget and mput in PSFTP, supporting wildcards. [originally from svn r4991] [this svn revision also touched putty-wishlist]
2004-12-16 17:35:20 +00:00
{
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
"mput", true, "upload multiple files at once",
" [ -r ] [ -- ] <filename-or-wildcard> [ <filename-or-wildcard>... ]\n"
" Uploads many files to the server, storing each one under the\n"
" same name it has on the client side. You can use wildcards\n"
" such as \"*.c\" to specify lots of files at once.\n"
" If -r specified, recursively store files and directories.\n",
sftp_cmd_mput
Implement mget and mput in PSFTP, supporting wildcards. [originally from svn r4991] [this svn revision also touched putty-wishlist]
2004-12-16 17:35:20 +00:00
},
Add online help in PSFTP. [originally from svn r1261]
2001-09-09 16:29:51 +00:00
{
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
"mv", true, "move or rename file(s) on the remote server",
" <source> [ <source>... ] <destination>\n"
" Moves or renames <source>(s) on the server to <destination>,\n"
" also on the server.\n"
" If <destination> specifies an existing directory, then <source>\n"
" may be a wildcard, and multiple <source>s may be given; all\n"
" source files are moved into <destination>.\n"
" Otherwise, <source> must specify a single file, which is moved\n"
" or renamed so that it is accessible under the name <destination>.\n",
sftp_cmd_mv
Add online help in PSFTP. [originally from svn r1261]
2001-09-09 16:29:51 +00:00
},
Allow PSFTP to be run with no arguments, in which case it enters the command-line state but all commands are disallowed except `open host.name'. The idea is to provide marginal extra niceness for people who double-click the icon without realising it's a cmdline app. [originally from svn r1480]
2001-12-13 18:42:34 +00:00
{
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
"open", true, "connect to a host",
" [<user>@]<hostname> [<port>]\n"
" Establishes an SFTP connection to a given host. Only usable\n"
" when you are not already connected to a server.\n",
sftp_cmd_open
Allow PSFTP to be run with no arguments, in which case it enters the command-line state but all commands are disallowed except `open host.name'. The idea is to provide marginal extra niceness for people who double-click the icon without realising it's a cmdline app. [originally from svn r1480]
2001-12-13 18:42:34 +00:00
},
The alphabetical ordering in the psftp command list was broken. D'oh! [originally from svn r1508]
2001-12-19 18:49:32 +00:00
{
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
"put", true, "upload a file from your local machine to the server",
" [ -r ] [ -- ] <filename> [ <remote-filename> ]\n"
" Uploads a file to the server and stores it there under\n"
" the same name, or under a different one if you supply the\n"
" argument <remote-filename>.\n"
" If -r specified, recursively store a directory.\n",
sftp_cmd_put
The alphabetical ordering in the psftp command list was broken. D'oh! [originally from svn r1508]
2001-12-19 18:49:32 +00:00
},
Add the `pwd' command in PSFTP. [originally from svn r1262]
2001-09-09 16:31:26 +00:00
{
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
"pwd", true, "print your remote working directory",
"\n"
" Print the current remote working directory for your SFTP session.\n",
sftp_cmd_pwd
Add the `pwd' command in PSFTP. [originally from svn r1262]
2001-09-09 16:31:26 +00:00
},
Add online help in PSFTP. [originally from svn r1261]
2001-09-09 16:29:51 +00:00
{
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
"quit", true, "bye", NULL,
sftp_cmd_quit
Add online help in PSFTP. [originally from svn r1261]
2001-09-09 16:29:51 +00:00
},
{
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
"reget", true, "continue downloading files",
" [ -r ] [ -- ] <filename> [ <local-filename> ]\n"
" Works exactly like the \"get\" command, but the local file\n"
" must already exist. The download will begin at the end of the\n"
" file. This is for resuming a download that was interrupted.\n"
" If -r specified, resume interrupted \"get -r\".\n",
sftp_cmd_reget
Add online help in PSFTP. [originally from svn r1261]
2001-09-09 16:29:51 +00:00
},
{
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
"ren", true, "mv", NULL,
sftp_cmd_mv
Add online help in PSFTP. [originally from svn r1261]
2001-09-09 16:29:51 +00:00
},
{
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
"rename", false, "mv", NULL,
sftp_cmd_mv
Add online help in PSFTP. [originally from svn r1261]
2001-09-09 16:29:51 +00:00
},
{
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
"reput", true, "continue uploading files",
" [ -r ] [ -- ] <filename> [ <remote-filename> ]\n"
" Works exactly like the \"put\" command, but the remote file\n"
" must already exist. The upload will begin at the end of the\n"
" file. This is for resuming an upload that was interrupted.\n"
" If -r specified, resume interrupted \"put -r\".\n",
sftp_cmd_reput
Add online help in PSFTP. [originally from svn r1261]
2001-09-09 16:29:51 +00:00
},
{
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
"rm", true, "del", NULL,
sftp_cmd_rm
Add online help in PSFTP. [originally from svn r1261]
2001-09-09 16:29:51 +00:00
},
{
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
"rmdir", true, "remove directories on the remote server",
" <directory-name> [ <directory-name>... ]\n"
" Removes the directory with the given name on the server.\n"
" The directory will not be removed unless it is empty.\n"
" Wildcards may be used to specify multiple directories.\n",
sftp_cmd_rmdir
Add online help in PSFTP. [originally from svn r1261]
2001-09-09 16:29:51 +00:00
}
};
Giant const-correctness patch of doom! Having found a lot of unfixed constness issues in recent development, I thought perhaps it was time to get proactive, so I compiled the whole codebase with -Wwrite-strings. That turned up a huge load of const problems, which I've fixed in this commit: the Unix build now goes cleanly through with -Wwrite-strings, and the Windows build is as close as I could get it (there are some lingering issues due to occasional Windows API functions like AcquireCredentialsHandle not having the right constness). Notable fallout beyond the purely mechanical changing of types: - the stuff saved by cmdline_save_param() is now explicitly dupstr()ed, and freed in cmdline_run_saved. - I couldn't make both string arguments to cmdline_process_param() const, because it intentionally writes to one of them in the case where it's the argument to -pw (in the vain hope of being at least slightly friendly to 'ps'), so elsewhere I had to temporarily dupstr() something for the sake of passing it to that function - I had to invent a silly parallel version of const_cmp() so I could pass const string literals in to lookup functions. - stripslashes() in pscp.c and psftp.c has the annoying strchr nature
2015-05-15 10:15:42 +00:00
const struct sftp_cmd_lookup *lookup_command(const char *name)
Add online help in PSFTP. [originally from svn r1261]
2001-09-09 16:29:51 +00:00
{
int i, j, k, cmp;
i = -1;
Replace all 'sizeof(x)/sizeof(*x)' with lenof. I noticed a few of these in the course of preparing the previous commit. I must have been writing that idiom out by hand for _ages_ before it became totally habitual to #define it as 'lenof' in every codebase I touch. Now I've gone through and replaced all the old verbosity with nice terse lenofs.
2019-01-04 07:13:08 +00:00
j = lenof(sftp_lookup);
Add online help in PSFTP. [originally from svn r1261]
2001-09-09 16:29:51 +00:00
while (j - i > 1) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
k = (j + i) / 2;
cmp = strcmp(name, sftp_lookup[k].name);
if (cmp < 0)
j = k;
else if (cmp > 0)
i = k;
else {
return &sftp_lookup[k];
}
Add online help in PSFTP. [originally from svn r1261]
2001-09-09 16:29:51 +00:00
}
return NULL;
}
static int sftp_cmd_help(struct sftp_command *cmd)
{
int i;
if (cmd->nwords == 1) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
/*
* Give short help on each command.
*/
int maxlen;
maxlen = 0;
for (i = 0; i < lenof(sftp_lookup); i++) {
int len;
if (!sftp_lookup[i].listed)
continue;
len = strlen(sftp_lookup[i].name);
if (maxlen < len)
maxlen = len;
}
for (i = 0; i < lenof(sftp_lookup); i++) {
const struct sftp_cmd_lookup *lookup;
if (!sftp_lookup[i].listed)
continue;
lookup = &sftp_lookup[i];
printf("%-*s", maxlen+2, lookup->name);
if (lookup->longhelp == NULL)
lookup = lookup_command(lookup->shorthelp);
printf("%s\n", lookup->shorthelp);
}
Add online help in PSFTP. [originally from svn r1261]
2001-09-09 16:29:51 +00:00
} else {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
/*
* Give long help on specific commands.
*/
for (i = 1; i < cmd->nwords; i++) {
const struct sftp_cmd_lookup *lookup;
lookup = lookup_command(cmd->words[i]);
if (!lookup) {
printf("help: %s: command not found\n", cmd->words[i]);
} else {
printf("%s", lookup->name);
if (lookup->longhelp == NULL)
lookup = lookup_command(lookup->shorthelp);
printf("%s", lookup->longhelp);
}
}
Add online help in PSFTP. [originally from svn r1261]
2001-09-09 16:29:51 +00:00
}
Tidied up PSFTP batch mode. The gross hack using fxp_error_message to report command failures is now gone; instead each sftp_cmd_* routine returns 0 or 1 depending on success, like they should have done right from the start. This fixes problems with `ls' prematurely terminating PSFTP batch files. [originally from svn r1481]
2001-12-13 19:26:51 +00:00
return 1;
Add online help in PSFTP. [originally from svn r1261]
2001-09-09 16:29:51 +00:00
}
First stab at an SFTP client. Currently a Unixland testing app, not integrated into PuTTY. [originally from svn r938]
2001-02-23 18:21:44 +00:00
/* ----------------------------------------------------------------------
* Command line reading and parsing.
*/
Patch to PSFTP: implement mkdir, rmdir, rm and scripting. Still to do: wildcards, chmod, mv, probably other things. [originally from svn r1168]
2001-08-04 14:19:51 +00:00
struct sftp_command *sftp_getcmd(FILE *fp, int mode, int modeflags)
Run entire source base through GNU indent to tidy up the varying coding styles of the various contributors! Woohoo! [originally from svn r1098]
2001-05-06 14:35:20 +00:00
{
First stab at an SFTP client. Currently a Unixland testing app, not integrated into PuTTY. [originally from svn r938]
2001-02-23 18:21:44 +00:00
char *line;
struct sftp_command *cmd;
char *p, *q, *r;
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
bool quoting;
First stab at an SFTP client. Currently a Unixland testing app, not integrated into PuTTY. [originally from svn r938]
2001-02-23 18:21:44 +00:00
Introduced wrapper macros snew(), snewn() and sresize() for the malloc functions, which automatically cast to the same type they're allocating the size of. Should prevent any future errors involving mallocing the size of the wrong structure type, and will also make life easier if we ever need to turn the PuTTY core code from real C into C++-friendly C. I haven't touched the Mac frontend in this checkin because I couldn't compile or test it. [originally from svn r3014]
2003-03-29 16:14:26 +00:00
cmd = snew(struct sftp_command);
First stab at an SFTP client. Currently a Unixland testing app, not integrated into PuTTY. [originally from svn r938]
2001-02-23 18:21:44 +00:00
cmd->words = NULL;
cmd->nwords = 0;
cmd->wordssize = 0;
line = NULL;
New timing infrastructure. There's a new function schedule_timer() which pretty much any module can call to request a call-back in the future. So terminal.c can do its own handling of blinking, visual bells and deferred screen updates, without having to rely on term_update() being called 50 times a second (fixes: pterm-timer); and ssh.c and telnet.c both invoke a new module pinger.c which takes care of sending keepalives, so they get sent uniformly in all front ends (fixes: plink-keepalives, unix-keepalives). [originally from svn r4906] [this svn revision also touched putty-wishlist]
2004-11-27 13:20:21 +00:00
if (fp) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
if (modeflags & 1)
printf("psftp> ");
line = fgetline(fp);
New timing infrastructure. There's a new function schedule_timer() which pretty much any module can call to request a call-back in the future. So terminal.c can do its own handling of blinking, visual bells and deferred screen updates, without having to rely on term_update() being called 50 times a second (fixes: pterm-timer); and ssh.c and telnet.c both invoke a new module pinger.c which takes care of sending keepalives, so they get sent uniformly in all front ends (fixes: plink-keepalives, unix-keepalives). [originally from svn r4906] [this svn revision also touched putty-wishlist]
2004-11-27 13:20:21 +00:00
} else {
Turn Backend into a sensible classoid. Nearly every part of the code that ever handles a full backend structure has historically done it using a pair of pointer variables, one pointing at a constant struct full of function pointers, and the other pointing to a 'void *' state object that's passed to each of those. While I'm modernising the rest of the code, this seems like a good time to turn that into the same more or less type-safe and less cumbersome system as I'm using for other parts of the code, such as Socket, Plug, BinaryPacketProtocol and so forth: the Backend structure contains a vtable pointer, and a system of macro wrappers handles dispatching through that vtable.
2018-09-11 15:23:38 +00:00
line = ssh_sftp_get_cmdline("psftp> ", !backend);
First stab at an SFTP client. Currently a Unixland testing app, not integrated into PuTTY. [originally from svn r938]
2001-02-23 18:21:44 +00:00
}
New timing infrastructure. There's a new function schedule_timer() which pretty much any module can call to request a call-back in the future. So terminal.c can do its own handling of blinking, visual bells and deferred screen updates, without having to rely on term_update() being called 50 times a second (fixes: pterm-timer); and ssh.c and telnet.c both invoke a new module pinger.c which takes care of sending keepalives, so they get sent uniformly in all front ends (fixes: plink-keepalives, unix-keepalives). [originally from svn r4906] [this svn revision also touched putty-wishlist]
2004-11-27 13:20:21 +00:00
if (!line || !*line) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
cmd->obey = sftp_cmd_quit;
if ((mode == 0) || (modeflags & 1))
printf("quit\n");
Fix another giant batch of resource leaks. (Mostly memory, but there's one missing fclose too.) [originally from svn r9919]
2013-07-14 10:46:07 +00:00
sfree(line);
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
return cmd; /* eof */
New timing infrastructure. There's a new function schedule_timer() which pretty much any module can call to request a call-back in the future. So terminal.c can do its own handling of blinking, visual bells and deferred screen updates, without having to rely on term_update() being called 50 times a second (fixes: pterm-timer); and ssh.c and telnet.c both invoke a new module pinger.c which takes care of sending keepalives, so they get sent uniformly in all front ends (fixes: plink-keepalives, unix-keepalives). [originally from svn r4906] [this svn revision also touched putty-wishlist]
2004-11-27 13:20:21 +00:00
}
line[strcspn(line, "\r\n")] = '\0';
Tidied up PSFTP batch mode. The gross hack using fxp_error_message to report command failures is now gone; instead each sftp_cmd_* routine returns 0 or 1 depending on success, like they should have done right from the start. This fixes problems with `ls' prematurely terminating PSFTP batch files. [originally from svn r1481]
2001-12-13 19:26:51 +00:00
if (modeflags & 1) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
printf("%s\n", line);
Tidied up PSFTP batch mode. The gross hack using fxp_error_message to report command failures is now gone; instead each sftp_cmd_* routine returns 0 or 1 depending on success, like they should have done right from the start. This fixes problems with `ls' prematurely terminating PSFTP batch files. [originally from svn r1481]
2001-12-13 19:26:51 +00:00
}
First stab at an SFTP client. Currently a Unixland testing app, not integrated into PuTTY. [originally from svn r938]
2001-02-23 18:21:44 +00:00
p = line;
Add the `local' command set to PSFTP: lcd, lpwd, and ! to spawn a Windows command. [originally from svn r1501]
2001-12-16 13:33:04 +00:00
while (*p && (*p == ' ' || *p == '\t'))
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
p++;
Add the `local' command set to PSFTP: lcd, lpwd, and ! to spawn a Windows command. [originally from svn r1501]
2001-12-16 13:33:04 +00:00
if (*p == '!') {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
/*
* Special case: the ! command. This is always parsed as
* exactly two words: one containing the !, and the second
* containing everything else on the line.
*/
New array-growing macros: sgrowarray and sgrowarrayn. The idea of these is that they centralise the common idiom along the lines of if (logical_array_len >= physical_array_size) { physical_array_size = logical_array_len * 5 / 4 + 256; array = sresize(array, physical_array_size, ElementType); } which happens at a zillion call sites throughout this code base, with different random choices of the geometric factor and additive constant, sometimes forgetting them completely, and generally doing a lot of repeated work. The new macro sgrowarray(array,size,n) has the semantics: here are the array pointer and its physical size for you to modify, now please ensure that the nth element exists, so I can write into it. And sgrowarrayn(array,size,n,m) is the same except that it ensures that the array has size at least n+m (so sgrowarray is just the special case where m=1). Now that this is a single centralised implementation that will be used everywhere, I've also gone to more effort in the implementation, with careful overflow checks that would have been painful to put at all the previous call sites. This commit also switches over every use of sresize(), apart from a few where I really didn't think it would gain anything. A consequence of that is that a lot of array-size variables have to have their types changed to size_t, because the macros require that (they address-take the size to pass to the underlying function).
2019-02-28 20:07:30 +00:00
cmd->nwords = 2;
sgrowarrayn(cmd->words, cmd->wordssize, cmd->nwords, 0);
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
cmd->words[0] = dupstr("!");
cmd->words[1] = dupstr(p+1);
Treat lines starting with '#' as comments in PSFTP. [originally from svn r8325]
2008-11-24 18:19:55 +00:00
} else if (*p == '#') {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
/*
* Special case: comment. Entire line is ignored.
*/
cmd->nwords = cmd->wordssize = 0;
Add the `local' command set to PSFTP: lcd, lpwd, and ! to spawn a Windows command. [originally from svn r1501]
2001-12-16 13:33:04 +00:00
} else {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
/*
* Parse the command line into words. The syntax is:
* - double quotes are removed, but cause spaces within to be
* treated as non-separating.
* - a double-doublequote pair is a literal double quote, inside
* _or_ outside quotes. Like this:
*
* firstword "second word" "this has ""quotes"" in" and""this""
*
* becomes
*
* >firstword<
* >second word<
* >this has "quotes" in<
* >and"this"<
*/
while (1) {
/* skip whitespace */
while (*p && (*p == ' ' || *p == '\t'))
p++;
Fix a bug in the PSFTP command parser which would cause it to hallucinate an extra empty argument word at the end of a line if the line ended in more than one whitespace character. [originally from svn r9613]
2012-08-22 18:36:44 +00:00
/* terminate loop */
if (!*p)
break;
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
/* mark start of word */
q = r = p; /* q sits at start, r writes word */
quoting = false;
while (*p) {
if (!quoting && (*p == ' ' || *p == '\t'))
break; /* reached end of word */
else if (*p == '"' && p[1] == '"')
p += 2, *r++ = '"'; /* a literal quote */
else if (*p == '"')
p++, quoting = !quoting;
else
*r++ = *p++;
}
if (*p)
p++; /* skip over the whitespace */
*r = '\0';
New array-growing macros: sgrowarray and sgrowarrayn. The idea of these is that they centralise the common idiom along the lines of if (logical_array_len >= physical_array_size) { physical_array_size = logical_array_len * 5 / 4 + 256; array = sresize(array, physical_array_size, ElementType); } which happens at a zillion call sites throughout this code base, with different random choices of the geometric factor and additive constant, sometimes forgetting them completely, and generally doing a lot of repeated work. The new macro sgrowarray(array,size,n) has the semantics: here are the array pointer and its physical size for you to modify, now please ensure that the nth element exists, so I can write into it. And sgrowarrayn(array,size,n,m) is the same except that it ensures that the array has size at least n+m (so sgrowarray is just the special case where m=1). Now that this is a single centralised implementation that will be used everywhere, I've also gone to more effort in the implementation, with careful overflow checks that would have been painful to put at all the previous call sites. This commit also switches over every use of sresize(), apart from a few where I really didn't think it would gain anything. A consequence of that is that a lot of array-size variables have to have their types changed to size_t, because the macros require that (they address-take the size to pass to the underlying function).
2019-02-28 20:07:30 +00:00
sgrowarray(cmd->words, cmd->wordssize, cmd->nwords);
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
cmd->words[cmd->nwords++] = dupstr(q);
}
First stab at an SFTP client. Currently a Unixland testing app, not integrated into PuTTY. [originally from svn r938]
2001-02-23 18:21:44 +00:00
}
New timing infrastructure. There's a new function schedule_timer() which pretty much any module can call to request a call-back in the future. So terminal.c can do its own handling of blinking, visual bells and deferred screen updates, without having to rely on term_update() being called 50 times a second (fixes: pterm-timer); and ssh.c and telnet.c both invoke a new module pinger.c which takes care of sending keepalives, so they get sent uniformly in all front ends (fixes: plink-keepalives, unix-keepalives). [originally from svn r4906] [this svn revision also touched putty-wishlist]
2004-11-27 13:20:21 +00:00
sfree(line);
First stab at an SFTP client. Currently a Unixland testing app, not integrated into PuTTY. [originally from svn r938]
2001-02-23 18:21:44 +00:00
/*
* Now parse the first word and assign a function.
*/
if (cmd->nwords == 0)
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
cmd->obey = sftp_cmd_null;
First stab at an SFTP client. Currently a Unixland testing app, not integrated into PuTTY. [originally from svn r938]
2001-02-23 18:21:44 +00:00
else {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
const struct sftp_cmd_lookup *lookup;
lookup = lookup_command(cmd->words[0]);
if (!lookup)
cmd->obey = sftp_cmd_unknown;
else
cmd->obey = lookup->obey;
First stab at an SFTP client. Currently a Unixland testing app, not integrated into PuTTY. [originally from svn r938]
2001-02-23 18:21:44 +00:00
}
return cmd;
}
Fix silly segfault due to PSFTP thinking connection is fine even if fxp_init() fails to get initial packet. [originally from svn r1565]
2002-02-27 22:20:30 +00:00
static int do_sftp_init(void)
Run entire source base through GNU indent to tidy up the varying coding styles of the various contributors! Woohoo! [originally from svn r1098]
2001-05-06 14:35:20 +00:00
{
First phase of SFTP re-engineering. Each base-level fxp_* function has been split into a send half and a receive half, so that callers can set several requests in motion at a time and deal with the responses in whatever order they arrive. [originally from svn r3318]
2003-06-29 14:26:09 +00:00
struct sftp_packet *pktin;
Clean up handling of the return value from sftp_find_request. In many places we simply enforce by assertion that it will match the request we sent out a moment ago: in fact it can also return NULL, so it makes more sense to report a proper error message if it doesn't return the expected value, and while we're at it, have that error message whatever message was helpfully left in fxp_error() by sftp_find_request when it failed. To do this, I've written a centralised function in psftp.c called sftp_wait_for_reply, which is handed a request that's just been sent out and deals with the mechanics of waiting for its reply, returning the reply when it arrives, and aborting with a sensible error if anything else arrives instead. The numerous sites in psftp.c which called sftp_find_request have all been rewritten to do this instead, and as a side effect they now look more sensible. The only other uses of sftp_find_request were in xfer_*load_gotpkt, which had to be tweaked in its own way. While I'm here, also fix memory management in sftp_find_request, which was freeing its input packet on some but not all error return paths. [originally from svn r9894]
2013-07-06 20:43:21 +00:00
struct sftp_request *req;
First phase of SFTP re-engineering. Each base-level fxp_* function has been split into a send half and a receive half, so that callers can set several requests in motion at a time and deal with the responses in whatever order they arrive. [originally from svn r3318]
2003-06-29 14:26:09 +00:00
First stab at an SFTP client. Currently a Unixland testing app, not integrated into PuTTY. [originally from svn r938]
2001-02-23 18:21:44 +00:00
/*
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
* Do protocol initialisation.
First stab at an SFTP client. Currently a Unixland testing app, not integrated into PuTTY. [originally from svn r938]
2001-02-23 18:21:44 +00:00
*/
if (!fxp_init()) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
fprintf(stderr,
"Fatal: unable to initialise SFTP: %s\n", fxp_error());
return 1; /* failure */
First stab at an SFTP client. Currently a Unixland testing app, not integrated into PuTTY. [originally from svn r938]
2001-02-23 18:21:44 +00:00
}
/*
* Find out where our home directory is.
*/
Clean up handling of the return value from sftp_find_request. In many places we simply enforce by assertion that it will match the request we sent out a moment ago: in fact it can also return NULL, so it makes more sense to report a proper error message if it doesn't return the expected value, and while we're at it, have that error message whatever message was helpfully left in fxp_error() by sftp_find_request when it failed. To do this, I've written a centralised function in psftp.c called sftp_wait_for_reply, which is handed a request that's just been sent out and deals with the mechanics of waiting for its reply, returning the reply when it arrives, and aborting with a sensible error if anything else arrives instead. The numerous sites in psftp.c which called sftp_find_request have all been rewritten to do this instead, and as a side effect they now look more sensible. The only other uses of sftp_find_request were in xfer_*load_gotpkt, which had to be tweaked in its own way. While I'm here, also fix memory management in sftp_find_request, which was freeing its input packet on some but not all error return paths. [originally from svn r9894]
2013-07-06 20:43:21 +00:00
req = fxp_realpath_send(".");
pktin = sftp_wait_for_reply(req);
homedir = fxp_realpath_recv(pktin, req);
First phase of SFTP re-engineering. Each base-level fxp_* function has been split into a send half and a receive half, so that callers can set several requests in motion at a time and deal with the responses in whatever order they arrive. [originally from svn r3318]
2003-06-29 14:26:09 +00:00
First stab at an SFTP client. Currently a Unixland testing app, not integrated into PuTTY. [originally from svn r938]
2001-02-23 18:21:44 +00:00
if (!homedir) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
fprintf(stderr,
"Warning: failed to resolve home directory: %s\n",
fxp_error());
homedir = dupstr(".");
First stab at an SFTP client. Currently a Unixland testing app, not integrated into PuTTY. [originally from svn r938]
2001-02-23 18:21:44 +00:00
} else {
File transfer tools: sanitise remote filenames and stderr. This commit adds sanitisation to PSCP and PSFTP in the same style as I've just put it into Plink. This time, standard error is sanitised without reference to whether it's redirected (at least unless you give an override option), on the basis that where Plink is _sometimes_ an SSH transport for some other protocol, PSCP and PSFTP _always_ are. But also, the sanitiser is run over any remote filename sent by the server, substituting ? for any control characters it finds. That removes another avenue for the server to deliberately confuse the display. This commit fixes our bug 'pscp-unsanitised-server-output', aka the two notional 'vulnerabilities' CVE-2019-6109 and CVE-2019-6110. (Although we regard those in isolation as only bugs, not serious vulnerabilities, because their main threat was in hiding the evidence of a server having exploited other more serious vulns that we never had.)
2019-02-20 07:09:10 +00:00
with_stripctrl(san, homedir)
printf("Remote working directory is %s\n", san);
First stab at an SFTP client. Currently a Unixland testing app, not integrated into PuTTY. [originally from svn r938]
2001-02-23 18:21:44 +00:00
}
pwd = dupstr(homedir);
Fix silly segfault due to PSFTP thinking connection is fine even if fxp_init() fails to get initial packet. [originally from svn r1565]
2002-02-27 22:20:30 +00:00
return 0;
Allow PSFTP to be run with no arguments, in which case it enters the command-line state but all commands are disallowed except `open host.name'. The idea is to provide marginal extra niceness for people who double-click the icon without realising it's a cmdline app. [originally from svn r1480]
2001-12-13 18:42:34 +00:00
}
Add missing 'static' on file-internal declarations. sk_startup and sk_nextaddr are entirely internal to winnet.c; nearly all of import.c and minibidi.c's internal routines should have been static and weren't; {read,write}_utf8 are internal to charset/utf8.c (and didn't even need separate declarations at all); do_sftp_cleanup is internal to psftp.c, and get_listitemheight to gtkdlg.c. While I was editing those prototypes anyway, I've also added missing 'const' to the 'char *' passphrase parameters in import,c.
2018-11-03 08:25:28 +00:00
static void do_sftp_cleanup(void)
Joe Yates's memory leak patches. [originally from svn r3650]
2003-12-19 12:44:46 +00:00
{
char ch;
Turn Backend into a sensible classoid. Nearly every part of the code that ever handles a full backend structure has historically done it using a pair of pointer variables, one pointing at a constant struct full of function pointers, and the other pointing to a 'void *' state object that's passed to each of those. While I'm modernising the rest of the code, this seems like a good time to turn that into the same more or less type-safe and less cumbersome system as I'm using for other parts of the code, such as Socket, Plug, BinaryPacketProtocol and so forth: the Backend structure contains a vtable pointer, and a system of macro wrappers handles dispatching through that vtable.
2018-09-11 15:23:38 +00:00
if (backend) {
Rework special-commands system to add an integer argument. In order to list cross-certifiable host keys in the GUI specials menu, the SSH backend has been inventing new values on the end of the Telnet_Special enumeration, starting from the value TS_LOCALSTART. This is inelegant, and also makes it awkward to break up special handlers (e.g. to dispatch different specials to different SSH layers), since if all you know about a special is that it's somewhere in the TS_LOCALSTART+n space, you can't tell what _general kind_ of thing it is. Also, if I ever need another open-ended set of specials in future, I'll have to remember which TS_LOCALSTART+n codes are in which set. So here's a revamp that causes every special to take an extra integer argument. For all previously numbered specials, this argument is passed as zero and ignored, but there's a new main special code for SSH host key cross-certification, in which the integer argument is an index into the backend's list of available keys. TS_LOCALSTART is now a thing of the past: if I need any other open-ended sets of specials in future, I can add a new top-level code with a nicely separated space of arguments. While I'm at it, I've removed the legacy misnomer 'Telnet_Special' from the code completely; the enum is now SessionSpecialCode, the struct containing full details of a menu entry is SessionSpecial, and the enum values now start SS_ rather than TS_.
2018-09-24 08:35:52 +00:00
backend_special(backend, SS_EOF, 0);
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
sent_eof = true;
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
sftp_recvdata(&ch, 1);
Turn Backend into a sensible classoid. Nearly every part of the code that ever handles a full backend structure has historically done it using a pair of pointer variables, one pointing at a constant struct full of function pointers, and the other pointing to a 'void *' state object that's passed to each of those. While I'm modernising the rest of the code, this seems like a good time to turn that into the same more or less type-safe and less cumbersome system as I'm using for other parts of the code, such as Socket, Plug, BinaryPacketProtocol and so forth: the Backend structure contains a vtable pointer, and a system of macro wrappers handles dispatching through that vtable.
2018-09-11 15:23:38 +00:00
backend_free(backend);
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
sftp_cleanup_request();
Turn Backend into a sensible classoid. Nearly every part of the code that ever handles a full backend structure has historically done it using a pair of pointer variables, one pointing at a constant struct full of function pointers, and the other pointing to a 'void *' state object that's passed to each of those. While I'm modernising the rest of the code, this seems like a good time to turn that into the same more or less type-safe and less cumbersome system as I'm using for other parts of the code, such as Socket, Plug, BinaryPacketProtocol and so forth: the Backend structure contains a vtable pointer, and a system of macro wrappers handles dispatching through that vtable.
2018-09-11 15:23:38 +00:00
backend = NULL;
Darryl L. Miles's patch to support an optional port number argument on the PSFTP `open' command; it was arguably a bug that this command couldn't do such an obvious thing that could be done from the main command line. Also had to fix a NULL-dereference in do_sftp_cleanup in the process. [originally from svn r3754]
2004-01-21 19:56:08 +00:00
}
Joe Yates's memory leak patches. [originally from svn r3650]
2003-12-19 12:44:46 +00:00
if (pwd) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
sfree(pwd);
pwd = NULL;
Joe Yates's memory leak patches. [originally from svn r3650]
2003-12-19 12:44:46 +00:00
}
if (homedir) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
sfree(homedir);
homedir = NULL;
Joe Yates's memory leak patches. [originally from svn r3650]
2003-12-19 12:44:46 +00:00
}
}
When PSFTP exits in batch mode due to a command failure, set exit status != 0. There are possibly other circumstances when PSFTP should also return failure, but that one seems particularly obvious.
2015-06-25 22:27:16 +00:00
int do_sftp(int mode, int modeflags, char *batchfile)
Allow PSFTP to be run with no arguments, in which case it enters the command-line state but all commands are disallowed except `open host.name'. The idea is to provide marginal extra niceness for people who double-click the icon without realising it's a cmdline app. [originally from svn r1480]
2001-12-13 18:42:34 +00:00
{
FILE *fp;
Tidied up PSFTP batch mode. The gross hack using fxp_error_message to report command failures is now gone; instead each sftp_cmd_* routine returns 0 or 1 depending on success, like they should have done right from the start. This fixes problems with `ls' prematurely terminating PSFTP batch files. [originally from svn r1481]
2001-12-13 19:26:51 +00:00
int ret;
First stab at an SFTP client. Currently a Unixland testing app, not integrated into PuTTY. [originally from svn r938]
2001-02-23 18:21:44 +00:00
Patch to PSFTP: implement mkdir, rmdir, rm and scripting. Still to do: wildcards, chmod, mv, probably other things. [originally from svn r1168]
2001-08-04 14:19:51 +00:00
/*
* Batch mode?
First stab at an SFTP client. Currently a Unixland testing app, not integrated into PuTTY. [originally from svn r938]
2001-02-23 18:21:44 +00:00
*/
Patch to PSFTP: implement mkdir, rmdir, rm and scripting. Still to do: wildcards, chmod, mv, probably other things. [originally from svn r1168]
2001-08-04 14:19:51 +00:00
if (mode == 0) {
/* ------------------------------------------------------------------
* Now we're ready to do Real Stuff.
*/
while (1) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
struct sftp_command *cmd;
cmd = sftp_getcmd(NULL, 0, 0);
if (!cmd)
break;
ret = cmd->obey(cmd);
if (cmd->words) {
int i;
for(i = 0; i < cmd->nwords; i++)
sfree(cmd->words[i]);
sfree(cmd->words);
}
sfree(cmd);
if (ret < 0)
break;
}
Patch to PSFTP: implement mkdir, rmdir, rm and scripting. Still to do: wildcards, chmod, mv, probably other things. [originally from svn r1168]
2001-08-04 14:19:51 +00:00
} else {
fp = fopen(batchfile, "r");
if (!fp) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
printf("Fatal: unable to open %s\n", batchfile);
return 1;
Patch to PSFTP: implement mkdir, rmdir, rm and scripting. Still to do: wildcards, chmod, mv, probably other things. [originally from svn r1168]
2001-08-04 14:19:51 +00:00
}
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
ret = 0;
Patch to PSFTP: implement mkdir, rmdir, rm and scripting. Still to do: wildcards, chmod, mv, probably other things. [originally from svn r1168]
2001-08-04 14:19:51 +00:00
while (1) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
struct sftp_command *cmd;
cmd = sftp_getcmd(fp, mode, modeflags);
if (!cmd)
break;
ret = cmd->obey(cmd);
if (ret < 0)
break;
if (ret == 0) {
if (!(modeflags & 2))
break;
}
Patch to PSFTP: implement mkdir, rmdir, rm and scripting. Still to do: wildcards, chmod, mv, probably other things. [originally from svn r1168]
2001-08-04 14:19:51 +00:00
}
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
fclose(fp);
/*
* In batch mode, and if exit on command failure is enabled,
* any command failure causes the whole of PSFTP to fail.
*/
if (ret == 0 && !(modeflags & 2)) return 2;
First stab at an SFTP client. Currently a Unixland testing app, not integrated into PuTTY. [originally from svn r938]
2001-02-23 18:21:44 +00:00
}
When PSFTP exits in batch mode due to a command failure, set exit status != 0. There are possibly other circumstances when PSFTP should also return failure, but that one seems particularly obvious.
2015-06-25 22:27:16 +00:00
return 0;
psftp now works as part of the PuTTY suite [originally from svn r940]
2001-02-24 16:08:56 +00:00
}
First stab at an SFTP client. Currently a Unixland testing app, not integrated into PuTTY. [originally from svn r938]
2001-02-23 18:21:44 +00:00
psftp now works as part of the PuTTY suite [originally from svn r940]
2001-02-24 16:08:56 +00:00
/* ----------------------------------------------------------------------
* Dirty bits: integration with PuTTY.
*/
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
static bool verbose = false;
psftp now works as part of the PuTTY suite [originally from svn r940]
2001-02-24 16:08:56 +00:00
Expose the Ldisc structure tag throughout the code. That's one fewer anonymous 'void *' which might be accidentally confused with some other pointer type if I misremember the order of function arguments. While I'm here, I've made its pointer-nature explicit - that is, 'Ldisc' is now a typedef for the structure type itself rather than a pointer to it. A stylistic change only, but it feels more natural to me these days for a thing you're going to eventually pass to a 'free' function.
2018-09-11 14:02:59 +00:00
void ldisc_echoedit_update(Ldisc *ldisc) { }
psftp now works as part of the PuTTY suite [originally from svn r940]
2001-02-24 16:08:56 +00:00
/*
* Receive a block of data from the SSH link. Block until all data
* is available.
*
* To do this, we repeatedly call the SSH protocol module, with our
New abstraction 'Seat', to pass to backends. This is a new vtable-based abstraction which is passed to a backend in place of Frontend, and it implements only the subset of the Frontend functions needed by a backend. (Many other Frontend functions still exist, notably the wide range of things called by terminal.c providing platform-independent operations on the GUI terminal window.) The purpose of making it a vtable is that this opens up the possibility of creating a backend as an internal implementation detail of some other activity, by providing just that one backend with a custom Seat that implements the methods differently. For example, this refactoring should make it feasible to directly implement an SSH proxy type, aka the 'jump host' feature supported by OpenSSH, aka 'open a secondary SSH session in MAINCHAN_DIRECT_TCP mode, and then expose the main channel of that as the Socket for the primary connection'. (Which of course you can already do by spawning 'plink -nc' as a separate proxy process, but this would permit it in the _same_ process without anything getting confused.) I've centralised a full set of stub methods in misc.c for the new abstraction, which allows me to get rid of several annoying stubs in the previous code. Also, while I'm here, I've moved a lot of duplicated modalfatalbox() type functions from application main program files into wincons.c / uxcons.c, which I think saves duplication overall. (A minor visible effect is that the prefixes on those console-based fatal error messages will now be more consistent between applications.)
2018-10-11 18:58:42 +00:00
* own psftp_output() function to catch the data that comes back. We
psftp now works as part of the PuTTY suite [originally from svn r940]
2001-02-24 16:08:56 +00:00
* do this until we have enough data.
*/
pscp, psftp: use a bufchain in ssh_scp_recv. The ad-hoc code that received data from the SCP or SFTP server predated even not-very-modern conveniences such as bufchain, and was quite horrible and cumbersome. Particularly nasty was the part where ssh_scp_recv set a _global_ pointer variable to the buffer it was in the middle of writing to, and then recursed and expected a callback to use that pointer. That caused clang-analyzer to grumble at me, in a particular case where the output buffer was in the ultimate caller's stack frame; even though I'm confident the code _worked_, I can't blame clang for being unhappy! So now we do things the modern and much simpler way: the callback when data comes in just puts it on a bufchain, and the top-level ssh_scp_recv repeatedly waits until data arrives in the bufchain and then copies it to the output buffer.
2018-12-01 09:56:32 +00:00
static bufchain received_data;
File transfer tools: sanitise remote filenames and stderr. This commit adds sanitisation to PSCP and PSFTP in the same style as I've just put it into Plink. This time, standard error is sanitised without reference to whether it's redirected (at least unless you give an override option), on the basis that where Plink is _sometimes_ an SSH transport for some other protocol, PSCP and PSFTP _always_ are. But also, the sanitiser is run over any remote filename sent by the server, substituting ? for any control characters it finds. That removes another avenue for the server to deliberately confuse the display. This commit fixes our bug 'pscp-unsanitised-server-output', aka the two notional 'vulnerabilities' CVE-2019-6109 and CVE-2019-6110. (Although we regard those in isolation as only bugs, not serious vulnerabilities, because their main threat was in hiding the evidence of a server having exploited other more serious vulns that we never had.)
2019-02-20 07:09:10 +00:00
static BinarySink *stderr_bs;
Make lots of 'int' length fields into size_t. This is a general cleanup which has been overdue for some time: lots of length fields are now the machine word type rather than the (in practice) fixed 'int'.
2019-02-06 20:42:44 +00:00
static size_t psftp_output(
Seat *seat, bool is_stderr, const void *data, size_t len)
Run entire source base through GNU indent to tidy up the varying coding styles of the various contributors! Woohoo! [originally from svn r1098]
2001-05-06 14:35:20 +00:00
{
psftp now works as part of the PuTTY suite [originally from svn r940]
2001-02-24 16:08:56 +00:00
/*
File transfer tools: sanitise remote filenames and stderr. This commit adds sanitisation to PSCP and PSFTP in the same style as I've just put it into Plink. This time, standard error is sanitised without reference to whether it's redirected (at least unless you give an override option), on the basis that where Plink is _sometimes_ an SSH transport for some other protocol, PSCP and PSFTP _always_ are. But also, the sanitiser is run over any remote filename sent by the server, substituting ? for any control characters it finds. That removes another avenue for the server to deliberately confuse the display. This commit fixes our bug 'pscp-unsanitised-server-output', aka the two notional 'vulnerabilities' CVE-2019-6109 and CVE-2019-6110. (Although we regard those in isolation as only bugs, not serious vulnerabilities, because their main threat was in hiding the evidence of a server having exploited other more serious vulns that we never had.)
2019-02-20 07:09:10 +00:00
* stderr data is just spouted to local stderr (optionally via a
* sanitiser) and otherwise ignored.
psftp now works as part of the PuTTY suite [originally from svn r940]
2001-02-24 16:08:56 +00:00
*/
if (is_stderr) {
File transfer tools: sanitise remote filenames and stderr. This commit adds sanitisation to PSCP and PSFTP in the same style as I've just put it into Plink. This time, standard error is sanitised without reference to whether it's redirected (at least unless you give an override option), on the basis that where Plink is _sometimes_ an SSH transport for some other protocol, PSCP and PSFTP _always_ are. But also, the sanitiser is run over any remote filename sent by the server, substituting ? for any control characters it finds. That removes another avenue for the server to deliberately confuse the display. This commit fixes our bug 'pscp-unsanitised-server-output', aka the two notional 'vulnerabilities' CVE-2019-6109 and CVE-2019-6110. (Although we regard those in isolation as only bugs, not serious vulnerabilities, because their main threat was in hiding the evidence of a server having exploited other more serious vulns that we never had.)
2019-02-20 07:09:10 +00:00
put_data(stderr_bs, data, len);
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
return 0;
psftp now works as part of the PuTTY suite [originally from svn r940]
2001-02-24 16:08:56 +00:00
}
pscp, psftp: use a bufchain in ssh_scp_recv. The ad-hoc code that received data from the SCP or SFTP server predated even not-very-modern conveniences such as bufchain, and was quite horrible and cumbersome. Particularly nasty was the part where ssh_scp_recv set a _global_ pointer variable to the buffer it was in the middle of writing to, and then recursed and expected a callback to use that pointer. That caused clang-analyzer to grumble at me, in a particular case where the output buffer was in the ultimate caller's stack frame; even though I'm confident the code _worked_, I can't blame clang for being unhappy! So now we do things the modern and much simpler way: the callback when data comes in just puts it on a bufchain, and the top-level ssh_scp_recv repeatedly waits until data arrives in the bufchain and then copies it to the output buffer.
2018-12-01 09:56:32 +00:00
bufchain_add(&received_data, data, len);
Extensive changes that _should_ fix the socket buffering problems, by ceasing to listen on input channels if the corresponding output channel isn't accepting data. Has had basic check-I-didn't-actually- break-anything-too-badly testing, but hasn't been genuinely tested in stress conditions (because concocting stress conditions is non- trivial). [originally from svn r1198]
2001-08-25 17:09:23 +00:00
return 0;
psftp now works as part of the PuTTY suite [originally from svn r940]
2001-02-24 16:08:56 +00:00
}
New abstraction 'Seat', to pass to backends. This is a new vtable-based abstraction which is passed to a backend in place of Frontend, and it implements only the subset of the Frontend functions needed by a backend. (Many other Frontend functions still exist, notably the wide range of things called by terminal.c providing platform-independent operations on the GUI terminal window.) The purpose of making it a vtable is that this opens up the possibility of creating a backend as an internal implementation detail of some other activity, by providing just that one backend with a custom Seat that implements the methods differently. For example, this refactoring should make it feasible to directly implement an SSH proxy type, aka the 'jump host' feature supported by OpenSSH, aka 'open a secondary SSH session in MAINCHAN_DIRECT_TCP mode, and then expose the main channel of that as the Socket for the primary connection'. (Which of course you can already do by spawning 'plink -nc' as a separate proxy process, but this would permit it in the _same_ process without anything getting confused.) I've centralised a full set of stub methods in misc.c for the new abstraction, which allows me to get rid of several annoying stubs in the previous code. Also, while I'm here, I've moved a lot of duplicated modalfatalbox() type functions from application main program files into wincons.c / uxcons.c, which I think saves duplication overall. (A minor visible effect is that the prefixes on those console-based fatal error messages will now be more consistent between applications.)
2018-10-11 18:58:42 +00:00
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
static bool psftp_eof(Seat *seat)
Revamp of EOF handling in all network connections, pipes and other data channels. Should comprehensively fix 'half-closed', in principle, though it's a big and complicated change and so there's a good chance I've made at least one mistake somewhere. All connections should now be rigorous about propagating end-of-file (or end-of-data-stream, or socket shutdown, or whatever) independently in both directions, except in frontends with no mechanism for sending explicit EOF (e.g. interactive terminal windows) or backends which are basically always used for interactive sessions so it's unlikely that an application would be depending on independent EOF (telnet, rlogin). EOF should now never accidentally be sent while there's still buffered data to go out before it. (May help fix 'portfwd-corrupt', and also I noticed recently that the ssh main session channel can accidentally have MSG_EOF sent before the output bufchain is clear, leading to embarrassment when it subsequently does send the output). [originally from svn r9279]
2011-09-13 11:44:03 +00:00
{
/*
* We expect to be the party deciding when to close the
* connection, so if we see EOF before we sent it ourselves, we
* should panic.
*/
if (!sent_eof) {
New abstraction 'Seat', to pass to backends. This is a new vtable-based abstraction which is passed to a backend in place of Frontend, and it implements only the subset of the Frontend functions needed by a backend. (Many other Frontend functions still exist, notably the wide range of things called by terminal.c providing platform-independent operations on the GUI terminal window.) The purpose of making it a vtable is that this opens up the possibility of creating a backend as an internal implementation detail of some other activity, by providing just that one backend with a custom Seat that implements the methods differently. For example, this refactoring should make it feasible to directly implement an SSH proxy type, aka the 'jump host' feature supported by OpenSSH, aka 'open a secondary SSH session in MAINCHAN_DIRECT_TCP mode, and then expose the main channel of that as the Socket for the primary connection'. (Which of course you can already do by spawning 'plink -nc' as a separate proxy process, but this would permit it in the _same_ process without anything getting confused.) I've centralised a full set of stub methods in misc.c for the new abstraction, which allows me to get rid of several annoying stubs in the previous code. Also, while I'm here, I've moved a lot of duplicated modalfatalbox() type functions from application main program files into wincons.c / uxcons.c, which I think saves duplication overall. (A minor visible effect is that the prefixes on those console-based fatal error messages will now be more consistent between applications.)
2018-10-11 18:58:42 +00:00
seat_connection_fatal(
psftp_seat, "Received unexpected end-of-file from SFTP server");
Revamp of EOF handling in all network connections, pipes and other data channels. Should comprehensively fix 'half-closed', in principle, though it's a big and complicated change and so there's a good chance I've made at least one mistake somewhere. All connections should now be rigorous about propagating end-of-file (or end-of-data-stream, or socket shutdown, or whatever) independently in both directions, except in frontends with no mechanism for sending explicit EOF (e.g. interactive terminal windows) or backends which are basically always used for interactive sessions so it's unlikely that an application would be depending on independent EOF (telnet, rlogin). EOF should now never accidentally be sent while there's still buffered data to go out before it. (May help fix 'portfwd-corrupt', and also I noticed recently that the ssh main session channel can accidentally have MSG_EOF sent before the output bufchain is clear, leading to embarrassment when it subsequently does send the output). [originally from svn r9279]
2011-09-13 11:44:03 +00:00
}
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
return false;
Revamp of EOF handling in all network connections, pipes and other data channels. Should comprehensively fix 'half-closed', in principle, though it's a big and complicated change and so there's a good chance I've made at least one mistake somewhere. All connections should now be rigorous about propagating end-of-file (or end-of-data-stream, or socket shutdown, or whatever) independently in both directions, except in frontends with no mechanism for sending explicit EOF (e.g. interactive terminal windows) or backends which are basically always used for interactive sessions so it's unlikely that an application would be depending on independent EOF (telnet, rlogin). EOF should now never accidentally be sent while there's still buffered data to go out before it. (May help fix 'portfwd-corrupt', and also I noticed recently that the ssh main session channel can accidentally have MSG_EOF sent before the output bufchain is clear, leading to embarrassment when it subsequently does send the output). [originally from svn r9279]
2011-09-13 11:44:03 +00:00
}
New abstraction 'Seat', to pass to backends. This is a new vtable-based abstraction which is passed to a backend in place of Frontend, and it implements only the subset of the Frontend functions needed by a backend. (Many other Frontend functions still exist, notably the wide range of things called by terminal.c providing platform-independent operations on the GUI terminal window.) The purpose of making it a vtable is that this opens up the possibility of creating a backend as an internal implementation detail of some other activity, by providing just that one backend with a custom Seat that implements the methods differently. For example, this refactoring should make it feasible to directly implement an SSH proxy type, aka the 'jump host' feature supported by OpenSSH, aka 'open a secondary SSH session in MAINCHAN_DIRECT_TCP mode, and then expose the main channel of that as the Socket for the primary connection'. (Which of course you can already do by spawning 'plink -nc' as a separate proxy process, but this would permit it in the _same_ process without anything getting confused.) I've centralised a full set of stub methods in misc.c for the new abstraction, which allows me to get rid of several annoying stubs in the previous code. Also, while I'm here, I've moved a lot of duplicated modalfatalbox() type functions from application main program files into wincons.c / uxcons.c, which I think saves duplication overall. (A minor visible effect is that the prefixes on those console-based fatal error messages will now be more consistent between applications.)
2018-10-11 18:58:42 +00:00
Make lots of 'int' length fields into size_t. This is a general cleanup which has been overdue for some time: lots of length fields are now the machine word type rather than the (in practice) fixed 'int'.
2019-02-06 20:42:44 +00:00
bool sftp_recvdata(char *buf, size_t len)
Run entire source base through GNU indent to tidy up the varying coding styles of the various contributors! Woohoo! [originally from svn r1098]
2001-05-06 14:35:20 +00:00
{
pscp, psftp: use a bufchain in ssh_scp_recv. The ad-hoc code that received data from the SCP or SFTP server predated even not-very-modern conveniences such as bufchain, and was quite horrible and cumbersome. Particularly nasty was the part where ssh_scp_recv set a _global_ pointer variable to the buffer it was in the middle of writing to, and then recursed and expected a callback to use that pointer. That caused clang-analyzer to grumble at me, in a particular case where the output buffer was in the ultimate caller's stack frame; even though I'm confident the code _worked_, I can't blame clang for being unhappy! So now we do things the modern and much simpler way: the callback when data comes in just puts it on a bufchain, and the top-level ssh_scp_recv repeatedly waits until data arrives in the bufchain and then copies it to the output buffer.
2018-12-01 09:56:32 +00:00
while (len > 0) {
while (bufchain_size(&received_data) == 0) {
if (backend_exitcode(backend) >= 0 ||
ssh_sftp_loop_iteration() < 0)
return false; /* doom */
}
psftp now works as part of the PuTTY suite [originally from svn r940]
2001-02-24 16:08:56 +00:00
Make lots of 'int' length fields into size_t. This is a general cleanup which has been overdue for some time: lots of length fields are now the machine word type rather than the (in practice) fixed 'int'.
2019-02-06 20:42:44 +00:00
size_t got = bufchain_fetch_consume_up_to(&received_data, buf, len);
pscp, psftp: use a bufchain in ssh_scp_recv. The ad-hoc code that received data from the SCP or SFTP server predated even not-very-modern conveniences such as bufchain, and was quite horrible and cumbersome. Particularly nasty was the part where ssh_scp_recv set a _global_ pointer variable to the buffer it was in the middle of writing to, and then recursed and expected a callback to use that pointer. That caused clang-analyzer to grumble at me, in a particular case where the output buffer was in the ultimate caller's stack frame; even though I'm confident the code _worked_, I can't blame clang for being unhappy! So now we do things the modern and much simpler way: the callback when data comes in just puts it on a bufchain, and the top-level ssh_scp_recv repeatedly waits until data arrives in the bufchain and then copies it to the output buffer.
2018-12-01 09:56:32 +00:00
buf += got;
len -= got;
psftp now works as part of the PuTTY suite [originally from svn r940]
2001-02-24 16:08:56 +00:00
}
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
return true;
psftp now works as part of the PuTTY suite [originally from svn r940]
2001-02-24 16:08:56 +00:00
}
Make lots of 'int' length fields into size_t. This is a general cleanup which has been overdue for some time: lots of length fields are now the machine word type rather than the (in practice) fixed 'int'.
2019-02-06 20:42:44 +00:00
bool sftp_senddata(const char *buf, size_t len)
Run entire source base through GNU indent to tidy up the varying coding styles of the various contributors! Woohoo! [originally from svn r1098]
2001-05-06 14:35:20 +00:00
{
Turn Backend into a sensible classoid. Nearly every part of the code that ever handles a full backend structure has historically done it using a pair of pointer variables, one pointing at a constant struct full of function pointers, and the other pointing to a 'void *' state object that's passed to each of those. While I'm modernising the rest of the code, this seems like a good time to turn that into the same more or less type-safe and less cumbersome system as I'm using for other parts of the code, such as Socket, Plug, BinaryPacketProtocol and so forth: the Backend structure contains a vtable pointer, and a system of macro wrappers handles dispatching through that vtable.
2018-09-11 15:23:38 +00:00
backend_send(backend, buf, len);
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
return true;
psftp now works as part of the PuTTY suite [originally from svn r940]
2001-02-24 16:08:56 +00:00
}
Make lots of 'int' length fields into size_t. This is a general cleanup which has been overdue for some time: lots of length fields are now the machine word type rather than the (in practice) fixed 'int'.
2019-02-06 20:42:44 +00:00
size_t sftp_sendbuffer(void)
Switch to flow-control-based SFTP uploading. Formerly PuTTY's SFTP code would transmit (or buffer) a megabyte of data before even starting to look for acknowledgements, but wouldn't allow there to be more than a megabyte of unacknowledged data at a time. Now, instead, it pays attention to whether the transmit path is blocked, and transmits iff it isn't. This should mean that SFTP goes faster over long fat pipes, and also doesn't end up buffering so much over thin ones. I practice, I tend to run into other performance limitations (such as TCP or SSH-2 windows) before this enhancement looks particularly good, but with an artificial lag of 250 ms on the loopback interface this patch almost doubles my upload speed, so I think it's worthwhile.
2016-04-08 23:24:12 +00:00
{
Turn Backend into a sensible classoid. Nearly every part of the code that ever handles a full backend structure has historically done it using a pair of pointer variables, one pointing at a constant struct full of function pointers, and the other pointing to a 'void *' state object that's passed to each of those. While I'm modernising the rest of the code, this seems like a good time to turn that into the same more or less type-safe and less cumbersome system as I'm using for other parts of the code, such as Socket, Plug, BinaryPacketProtocol and so forth: the Backend structure contains a vtable pointer, and a system of macro wrappers handles dispatching through that vtable.
2018-09-11 15:23:38 +00:00
return backend_sendbuffer(backend);
Switch to flow-control-based SFTP uploading. Formerly PuTTY's SFTP code would transmit (or buffer) a megabyte of data before even starting to look for acknowledgements, but wouldn't allow there to be more than a megabyte of unacknowledged data at a time. Now, instead, it pays attention to whether the transmit path is blocked, and transmits iff it isn't. This should mean that SFTP goes faster over long fat pipes, and also doesn't end up buffering so much over thin ones. I practice, I tend to run into other performance limitations (such as TCP or SSH-2 windows) before this enhancement looks particularly good, but with an artificial lag of 250 ms on the loopback interface this patch almost doubles my upload speed, so I think it's worthwhile.
2016-04-08 23:24:12 +00:00
}
psftp now works as part of the PuTTY suite [originally from svn r940]
2001-02-24 16:08:56 +00:00
/*
* Short description of parameters.
*/
static void usage(void)
{
printf("PuTTY Secure File Transfer (SFTP) client\n");
printf("%s\n", ver);
Correct slightly misleading usage [originally from svn r3889]
2004-02-22 14:57:40 +00:00
printf("Usage: psftp [options] [user@]host\n");
psftp now works as part of the PuTTY suite [originally from svn r940]
2001-02-24 16:08:56 +00:00
printf("Options:\n");
Try to make our PGP signing more useful: * All the PuTTY tools for Windows and Unix now contain the fingerprints of the Master Keys. The method for accessing them is crude but universal: a new "-pgpfp" command-line option. (Except Unix PuTTYgen, which takes "--pgpfp" just to be awkward.) * Move the key policy discussion from putty-website/keys.html to putty/doc/pgpkeys.but, and autogenerate the former from the latter. Also tweak the text somewhat and include the fingerprints of the Master Keys themselves. (I've merged the existing autogeneration scripts into a single new one; I've left the old scripts and keys.html around until such time as the webmonster reviews the changes and plumbs in the new script; he should remove the old files then.) [originally from svn r5524] [this svn revision also touched putty-website]
2005-03-19 02:26:58 +00:00
printf(" -V print version information and exit\n");
printf(" -pgpfp print PGP key fingerprints and exit\n");
Patch to PSFTP: implement mkdir, rmdir, rm and scripting. Still to do: wildcards, chmod, mv, probably other things. [originally from svn r1168]
2001-08-04 14:19:51 +00:00
printf(" -b file use specified batchfile\n");
printf(" -bc output batchfile commands\n");
printf(" -be don't stop batchfile processing if errors\n");
psftp now works as part of the PuTTY suite [originally from svn r940]
2001-02-24 16:08:56 +00:00
printf(" -v show verbose messages\n");
Updated usage messages for command-line utilities to reflect new options. Updated manual to reflect reality (e.g. usage messages, '-p port' not actually implemented, sprinkle references to '-i keyfile'). (I've put "Release 0.53" in the messages; let's hope this doesn't cause a flood of "where is 0.53?" email.) I don't guarantee that the result is entirely sane and sensible in all respects, but it is at least consistent. [originally from svn r1951]
2002-09-11 17:30:36 +00:00
printf(" -load sessname Load settings from saved session\n");
printf(" -l user connect with specified username\n");
psftp now works as part of the PuTTY suite [originally from svn r940]
2001-02-24 16:08:56 +00:00
printf(" -P port connect to specified port\n");
printf(" -pw passw login with specified password\n");
Updated usage messages for command-line utilities to reflect new options. Updated manual to reflect reality (e.g. usage messages, '-p port' not actually implemented, sprinkle references to '-i keyfile'). (I've put "Release 0.53" in the messages; let's hope this doesn't cause a flood of "where is 0.53?" email.) I don't guarantee that the result is entirely sane and sensible in all respects, but it is at least consistent. [originally from svn r1951]
2002-09-11 17:30:36 +00:00
printf(" -1 -2 force use of particular SSH protocol version\n");
Integrate unfix.org's IPv6 patches up to level 10, with rather a lot of polishing to bring them to what I think should in principle be release quality. Unlike the unfix.org patches themselves, this checkin enables IPv6 by default; if you want to leave it out, you have to build with COMPAT=-DNO_IPV6. I have tested that this compiles on Visual C 7 (so the nightlies _should_ acquire IPv6 support without missing a beat), but since I don't have IPv6 set up myself I haven't actually tested that it _works_. It still seems to make correct IPv4 connections, but that's all I've been able to verify for myself. Further testing is needed. [originally from svn r5047] [this svn revision also touched putty-wishlist]
2004-12-30 16:45:11 +00:00
printf(" -4 -6 force use of IPv4 or IPv6\n");
Updated usage messages for command-line utilities to reflect new options. Updated manual to reflect reality (e.g. usage messages, '-p port' not actually implemented, sprinkle references to '-i keyfile'). (I've put "Release 0.53" in the messages; let's hope this doesn't cause a flood of "where is 0.53?" email.) I don't guarantee that the result is entirely sane and sensible in all respects, but it is at least consistent. [originally from svn r1951]
2002-09-11 17:30:36 +00:00
printf(" -C enable compression\n");
Update command-line help and man pages for -hostkey. [originally from svn r10229]
2014-09-20 22:49:47 +00:00
printf(" -i key private key file for user authentication\n");
Fix up documentation/usage messages for r6572. [originally from svn r6574] [r6572 == c2b2d9c5390272d05cea55271db130a24281d81f]
2006-02-19 12:52:28 +00:00
printf(" -noagent disable use of Pageant\n");
printf(" -agent enable use of Pageant\n");
Update command-line help and man pages for -hostkey. [originally from svn r10229]
2014-09-20 22:49:47 +00:00
printf(" -hostkey aa:bb:cc:...\n");
printf(" manually specify a host key (may be repeated)\n");
Updated usage messages for command-line utilities to reflect new options. Updated manual to reflect reality (e.g. usage messages, '-p port' not actually implemented, sprinkle references to '-i keyfile'). (I've put "Release 0.53" in the messages; let's hope this doesn't cause a flood of "where is 0.53?" email.) I don't guarantee that the result is entirely sane and sensible in all respects, but it is at least consistent. [originally from svn r1951]
2002-09-11 17:30:36 +00:00
printf(" -batch disable all interactive prompts\n");
File transfer tools: sanitise remote filenames and stderr. This commit adds sanitisation to PSCP and PSFTP in the same style as I've just put it into Plink. This time, standard error is sanitised without reference to whether it's redirected (at least unless you give an override option), on the basis that where Plink is _sometimes_ an SSH transport for some other protocol, PSCP and PSFTP _always_ are. But also, the sanitiser is run over any remote filename sent by the server, substituting ? for any control characters it finds. That removes another avenue for the server to deliberately confuse the display. This commit fixes our bug 'pscp-unsanitised-server-output', aka the two notional 'vulnerabilities' CVE-2019-6109 and CVE-2019-6110. (Although we regard those in isolation as only bugs, not serious vulnerabilities, because their main threat was in hiding the evidence of a server having exploited other more serious vulns that we never had.)
2019-02-20 07:09:10 +00:00
printf(" -no-sanitise-stderr don't strip control chars from"
" standard error\n");
Document -proxycmd in help and man pages. Also, in the main documentation, note the hazard that backslashes in the command argument must be doubled.
2017-02-11 23:03:46 +00:00
printf(" -proxycmd command\n");
printf(" use 'command' as local proxy\n");
Rationalise and document log options somewhat. TOOLTYPE_NONNETWORK (i.e. pterm) already has "-log" (as does Unix PuTTY), so there's no sense suppressing the synonym "-sessionlog". Undocumented lacunae that remain: plink accepts -sessionlog, but does nothing with it. Arguably it should. puttytel accepts -sshlog/-sshrawlog (and happily logs e.g. Telnet negotiation, as does PuTTY proper).
2015-11-08 11:57:39 +00:00
printf(" -sshlog file\n");
printf(" -sshrawlog file\n");
printf(" log protocol details to a file\n");
Ensure our network layer is properly cleaned up before PuTTY exits. Specifically, we explicitly closesocket() all open sockets, which appears to be necessary since otherwise Windows sends RST rather than FIN. I'm _sure_ that's a Windows bug, but there we go. [originally from svn r1574]
2002-03-06 20:13:22 +00:00
cleanup_exit(1);
psftp now works as part of the PuTTY suite [originally from svn r940]
2001-02-24 16:08:56 +00:00
}
Add -V for version information to plink, pscp, and psftp. [originally from svn r4092]
2004-04-17 20:25:09 +00:00
static void version(void)
{
Include 'build info' in all --version text and About boxes. This shows the build platform (32- vs 64-bit in particular, and also whether Unix GTK builds were compiled with or without the X11 pieces), what compiler was used to build the binary, and any interesting build options that might have been set on the make command line (especially, but not limited to, the security-damaging ones like NO_SECURITY or UNPROTECT). This will probably be useful all over the place, but in particular it should allow the different Windows binaries to be told apart! Commits 21101c739 and 2eb952ca3 laid the groundwork for this, by allowing the various About boxes to contain free text and also ensuring they could be copied and pasted easily as part of a bug report.
2017-01-21 14:55:53 +00:00
char *buildinfo_text = buildinfo("\n");
printf("psftp: %s\n%s\n", ver, buildinfo_text);
sfree(buildinfo_text);
Return zero when reporting our version. When called with -V to ask for our version, return 0 rather than 1. This is the usual behaviour observed by ssh(1) and other Unix commands. Also use exit() rather than cleanup_exit() in pscp.c and psftp.c ; at this point we have nothing to cleanup!
2017-02-15 19:50:14 +00:00
exit(0);
Add -V for version information to plink, pscp, and psftp. [originally from svn r4092]
2004-04-17 20:25:09 +00:00
}
psftp now works as part of the PuTTY suite [originally from svn r940]
2001-02-24 16:08:56 +00:00
/*
Allow PSFTP to be run with no arguments, in which case it enters the command-line state but all commands are disallowed except `open host.name'. The idea is to provide marginal extra niceness for people who double-click the icon without realising it's a cmdline app. [originally from svn r1480]
2001-12-13 18:42:34 +00:00
* Connect to a host.
psftp now works as part of the PuTTY suite [originally from svn r940]
2001-02-24 16:08:56 +00:00
*/
Allow PSFTP to be run with no arguments, in which case it enters the command-line state but all commands are disallowed except `open host.name'. The idea is to provide marginal extra niceness for people who double-click the icon without realising it's a cmdline app. [originally from svn r1480]
2001-12-13 18:42:34 +00:00
static int psftp_connect(char *userhost, char *user, int portnumber)
psftp now works as part of the PuTTY suite [originally from svn r940]
2001-02-24 16:08:56 +00:00
{
Allow PSFTP to be run with no arguments, in which case it enters the command-line state but all commands are disallowed except `open host.name'. The idea is to provide marginal extra niceness for people who double-click the icon without realising it's a cmdline app. [originally from svn r1480]
2001-12-13 18:42:34 +00:00
char *host, *realhost;
Colin's const-fixing Patch Of Death. Seems to build fine on Windows as well as Unix, so it can go in. [originally from svn r3162]
2003-05-04 14:18:18 +00:00
const char *err;
psftp now works as part of the PuTTY suite [originally from svn r940]
2001-02-24 16:08:56 +00:00
/* Separate host and username */
host = userhost;
host = strrchr(host, '@');
if (host == NULL) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
host = userhost;
psftp now works as part of the PuTTY suite [originally from svn r940]
2001-02-24 16:08:56 +00:00
} else {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
*host++ = '\0';
if (user) {
printf("psftp: multiple usernames specified; using \"%s\"\n",
user);
} else
user = userhost;
psftp now works as part of the PuTTY suite [originally from svn r940]
2001-02-24 16:08:56 +00:00
}
Fix for `psftp-pscp-ignore-load': Default Settings is now loaded before "-load" is processed so that it doesn't clobber it. I've also changed the semantics of "-load" slightly for PSCP, PSFTP, and Plink: if it's specified at all, it overrides (disables) the implicit loading of session details based on a supplied hostname elsewhere (on the grounds that the user is more likely to want the "-load" session than the implicit session). (PuTTY itself doesn't do implicit loading at all, so I haven't changed it.) This means that all the PuTTY tools' behaviour is now consistent iff "-load" is specified (otherwise, some tools have implicit-session, and others don't). However, I've not documented this behaviour, as there's a good chance it will be swept away if and when we get round to sorting out how we deal with settings from multiple sources. It's intended as a "do something sensible" change. [originally from svn r4352]
2004-07-25 14:00:26 +00:00
/*
* If we haven't loaded session details already (e.g., from -load),
* try looking for a session called "host".
*/
Move 'loaded_session' into cmdline.c. I haven't managed to make this one _not_ be a mutable variable, but at least it's not global across all tools any more: it lives in cmdline.c along with the code that decides what to set it to, and cmdline.c exports a query method to ask for its value.
2020-01-30 06:40:22 +00:00
if (!cmdline_loaded_session()) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
/* Try to load settings for `host' into a temporary config */
Conf *conf2 = conf_new();
conf_set_str(conf2, CONF_host, "");
do_defaults(host, conf2);
if (conf_get_str(conf2, CONF_host)[0] != '\0') {
/* Settings present and include hostname */
/* Re-load data into the real config. */
do_defaults(host, conf);
} else {
/* Session doesn't exist or mention a hostname. */
/* Use `host' as a bare hostname. */
conf_set_str(conf, CONF_host, host);
}
Fix a few more memory and resource leaks. [originally from svn r9968]
2013-07-22 19:55:55 +00:00
conf_free(conf2);
Fix for `psftp-pscp-ignore-load': Default Settings is now loaded before "-load" is processed so that it doesn't clobber it. I've also changed the semantics of "-load" slightly for PSCP, PSFTP, and Plink: if it's specified at all, it overrides (disables) the implicit loading of session details based on a supplied hostname elsewhere (on the grounds that the user is more likely to want the "-load" session than the implicit session). (PuTTY itself doesn't do implicit loading at all, so I haven't changed it.) This means that all the PuTTY tools' behaviour is now consistent iff "-load" is specified (otherwise, some tools have implicit-session, and others don't). However, I've not documented this behaviour, as there's a good chance it will be swept away if and when we get round to sorting out how we deal with settings from multiple sources. It's intended as a "do something sensible" change. [originally from svn r4352]
2004-07-25 14:00:26 +00:00
} else {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
/* Patch in hostname `host' to session details. */
conf_set_str(conf, CONF_host, host);
Fix pscp-cmdline-port-bug for PSFTP too. (Also removes what appears to be a gratuitous re-implementation of the "-l user" option.) [originally from svn r1997]
2002-10-07 17:31:52 +00:00
}
/*
* Force use of SSH. (If they got the protocol wrong we assume the
* port is useless too.)
*/
Post-release destabilisation! Completely remove the struct type 'Config' in putty.h, which stores all PuTTY's settings and includes an arbitrary length limit on every single one of those settings which is stored in string form. In place of it is 'Conf', an opaque data type everywhere outside the new file conf.c, which stores a list of (key, value) pairs in which every key contains an integer identifying a configuration setting, and for some of those integers the key also contains extra parts (so that, for instance, CONF_environmt is a string-to-string mapping). Everywhere that a Config was previously used, a Conf is now; everywhere there was a Config structure copy, conf_copy() is called; every lookup, adjustment, load and save operation on a Config has been rewritten; and there's a mechanism for serialising a Conf into a binary blob and back for use with Duplicate Session. User-visible effects of this change _should_ be minimal, though I don't doubt I've introduced one or two bugs here and there which will eventually be found. The _intended_ visible effects of this change are that all arbitrary limits on configuration strings and lists (e.g. limit on number of port forwardings) should now disappear; that list boxes in the configuration will now be displayed in a sorted order rather than the arbitrary order in which they were added to the list (since the underlying data structure is now a sorted tree234 rather than an ad-hoc comma-separated string); and one more specific change, which is that local and dynamic port forwardings on the same port number are now mutually exclusive in the configuration (putting 'D' in the key rather than the value was a mistake in the first place). One other reorganisation as a result of this is that I've moved all the dialog.c standard handlers (dlg_stdeditbox_handler and friends) out into config.c, because I can't really justify calling them generic any more. When they took a pointer to an arbitrary structure type and the offset of a field within that structure, they were independent of whether that structure was a Config or something completely different, but now they really do expect to talk to a Conf, which can _only_ be used for PuTTY configuration, so I've renamed them all things like conf_editbox_handler and moved them out of the nominally independent dialog-box management module into the PuTTY-specific config.c. [originally from svn r9214]
2011-07-14 18:52:21 +00:00
if (conf_get_int(conf, CONF_protocol) != PROT_SSH) {
conf_set_int(conf, CONF_protocol, PROT_SSH);
conf_set_int(conf, CONF_port, 22);
psftp now works as part of the PuTTY suite [originally from svn r940]
2001-02-24 16:08:56 +00:00
}
PSFTP was ignoring `-1' and `-2' and always using SSH-2 with fallback to SSH-1. It also ignored any settings forbidding fallback to SSH-1. Ignoring `-1' and `-2' is hardly the end of the world, as it'd be difficult to think of a realistic situation where fallback didn't do the right thing and PSFTP was still useful. However, ignoring a user's `SSH-2 only' setting was a bit rude. [originally from svn r4357]
2004-07-25 16:10:48 +00:00
/*
* If saved session / Default Settings says SSH-1 (`1 only' or `1'),
* then change it to SSH-2, on the grounds that that's more likely to
* work for SFTP. (Can be overridden with `-1' option.)
* But if it says `2 only' or `2', respect which.
*/
Post-release destabilisation! Completely remove the struct type 'Config' in putty.h, which stores all PuTTY's settings and includes an arbitrary length limit on every single one of those settings which is stored in string form. In place of it is 'Conf', an opaque data type everywhere outside the new file conf.c, which stores a list of (key, value) pairs in which every key contains an integer identifying a configuration setting, and for some of those integers the key also contains extra parts (so that, for instance, CONF_environmt is a string-to-string mapping). Everywhere that a Config was previously used, a Conf is now; everywhere there was a Config structure copy, conf_copy() is called; every lookup, adjustment, load and save operation on a Config has been rewritten; and there's a mechanism for serialising a Conf into a binary blob and back for use with Duplicate Session. User-visible effects of this change _should_ be minimal, though I don't doubt I've introduced one or two bugs here and there which will eventually be found. The _intended_ visible effects of this change are that all arbitrary limits on configuration strings and lists (e.g. limit on number of port forwardings) should now disappear; that list boxes in the configuration will now be displayed in a sorted order rather than the arbitrary order in which they were added to the list (since the underlying data structure is now a sorted tree234 rather than an ad-hoc comma-separated string); and one more specific change, which is that local and dynamic port forwardings on the same port number are now mutually exclusive in the configuration (putting 'D' in the key rather than the value was a mistake in the first place). One other reorganisation as a result of this is that I've moved all the dialog.c standard handlers (dlg_stdeditbox_handler and friends) out into config.c, because I can't really justify calling them generic any more. When they took a pointer to an arbitrary structure type and the offset of a field within that structure, they were independent of whether that structure was a Config or something completely different, but now they really do expect to talk to a Conf, which can _only_ be used for PuTTY configuration, so I've renamed them all things like conf_editbox_handler and moved them out of the nominally independent dialog-box management module into the PuTTY-specific config.c. [originally from svn r9214]
2011-07-14 18:52:21 +00:00
if ((conf_get_int(conf, CONF_sshprot) & ~1) != 2) /* is it 2 or 3? */
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
conf_set_int(conf, CONF_sshprot, 2);
PSFTP was ignoring `-1' and `-2' and always using SSH-2 with fallback to SSH-1. It also ignored any settings forbidding fallback to SSH-1. Ignoring `-1' and `-2' is hardly the end of the world, as it'd be difficult to think of a realistic situation where fallback didn't do the right thing and PSFTP was still useful. However, ignoring a user's `SSH-2 only' setting was a bit rude. [originally from svn r4357]
2004-07-25 16:10:48 +00:00
Revamp of command-line handling. Most command line options should now be processed in cmdline.c, which is called from all utilities (well, not Pageant or PuTTYgen). This should mean we get to standardise almost all options across almost all tools. Also one major change: `-load' is now the preferred option for loading a saved session in PuTTY proper. `@session' still works but is deprecated. [originally from svn r1799]
2002-08-04 21:18:56 +00:00
/*
* Enact command-line overrides.
*/
Post-release destabilisation! Completely remove the struct type 'Config' in putty.h, which stores all PuTTY's settings and includes an arbitrary length limit on every single one of those settings which is stored in string form. In place of it is 'Conf', an opaque data type everywhere outside the new file conf.c, which stores a list of (key, value) pairs in which every key contains an integer identifying a configuration setting, and for some of those integers the key also contains extra parts (so that, for instance, CONF_environmt is a string-to-string mapping). Everywhere that a Config was previously used, a Conf is now; everywhere there was a Config structure copy, conf_copy() is called; every lookup, adjustment, load and save operation on a Config has been rewritten; and there's a mechanism for serialising a Conf into a binary blob and back for use with Duplicate Session. User-visible effects of this change _should_ be minimal, though I don't doubt I've introduced one or two bugs here and there which will eventually be found. The _intended_ visible effects of this change are that all arbitrary limits on configuration strings and lists (e.g. limit on number of port forwardings) should now disappear; that list boxes in the configuration will now be displayed in a sorted order rather than the arbitrary order in which they were added to the list (since the underlying data structure is now a sorted tree234 rather than an ad-hoc comma-separated string); and one more specific change, which is that local and dynamic port forwardings on the same port number are now mutually exclusive in the configuration (putting 'D' in the key rather than the value was a mistake in the first place). One other reorganisation as a result of this is that I've moved all the dialog.c standard handlers (dlg_stdeditbox_handler and friends) out into config.c, because I can't really justify calling them generic any more. When they took a pointer to an arbitrary structure type and the offset of a field within that structure, they were independent of whether that structure was a Config or something completely different, but now they really do expect to talk to a Conf, which can _only_ be used for PuTTY configuration, so I've renamed them all things like conf_editbox_handler and moved them out of the nominally independent dialog-box management module into the PuTTY-specific config.c. [originally from svn r9214]
2011-07-14 18:52:21 +00:00
cmdline_run_saved(conf);
Revamp of command-line handling. Most command line options should now be processed in cmdline.c, which is called from all utilities (well, not Pageant or PuTTYgen). This should mean we get to standardise almost all options across almost all tools. Also one major change: `-load' is now the preferred option for loading a saved session in PuTTY proper. `@session' still works but is deprecated. [originally from svn r1799]
2002-08-04 21:18:56 +00:00
The other utilities should do the same processing of the hostname (parsing `user@' prefixes etc) that PuTTY proper does. [originally from svn r1346]
2001-10-30 21:45:27 +00:00
/*
Post-release destabilisation! Completely remove the struct type 'Config' in putty.h, which stores all PuTTY's settings and includes an arbitrary length limit on every single one of those settings which is stored in string form. In place of it is 'Conf', an opaque data type everywhere outside the new file conf.c, which stores a list of (key, value) pairs in which every key contains an integer identifying a configuration setting, and for some of those integers the key also contains extra parts (so that, for instance, CONF_environmt is a string-to-string mapping). Everywhere that a Config was previously used, a Conf is now; everywhere there was a Config structure copy, conf_copy() is called; every lookup, adjustment, load and save operation on a Config has been rewritten; and there's a mechanism for serialising a Conf into a binary blob and back for use with Duplicate Session. User-visible effects of this change _should_ be minimal, though I don't doubt I've introduced one or two bugs here and there which will eventually be found. The _intended_ visible effects of this change are that all arbitrary limits on configuration strings and lists (e.g. limit on number of port forwardings) should now disappear; that list boxes in the configuration will now be displayed in a sorted order rather than the arbitrary order in which they were added to the list (since the underlying data structure is now a sorted tree234 rather than an ad-hoc comma-separated string); and one more specific change, which is that local and dynamic port forwardings on the same port number are now mutually exclusive in the configuration (putting 'D' in the key rather than the value was a mistake in the first place). One other reorganisation as a result of this is that I've moved all the dialog.c standard handlers (dlg_stdeditbox_handler and friends) out into config.c, because I can't really justify calling them generic any more. When they took a pointer to an arbitrary structure type and the offset of a field within that structure, they were independent of whether that structure was a Config or something completely different, but now they really do expect to talk to a Conf, which can _only_ be used for PuTTY configuration, so I've renamed them all things like conf_editbox_handler and moved them out of the nominally independent dialog-box management module into the PuTTY-specific config.c. [originally from svn r9214]
2011-07-14 18:52:21 +00:00
* Muck about with the hostname in various ways.
The other utilities should do the same processing of the hostname (parsing `user@' prefixes etc) that PuTTY proper does. [originally from svn r1346]
2001-10-30 21:45:27 +00:00
*/
{
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
char *hostbuf = dupstr(conf_get_str(conf, CONF_host));
char *host = hostbuf;
char *p, *q;
/*
* Trim leading whitespace.
*/
host += strspn(host, " \t");
/*
* See if host is of the form user@host, and separate out
* the username if so.
*/
if (host[0] != '\0') {
char *atsign = strrchr(host, '@');
if (atsign) {
*atsign = '\0';
conf_set_str(conf, CONF_username, host);
host = atsign + 1;
}
}
/*
* Remove any remaining whitespace.
*/
p = hostbuf;
q = host;
while (*q) {
if (*q != ' ' && *q != '\t')
*p++ = *q;
q++;
}
*p = '\0';
conf_set_str(conf, CONF_host, hostbuf);
sfree(hostbuf);
Fix for `hostname-whitespace'; thanks to Justin Bradford. [originally from svn r2080]
2002-10-16 11:35:13 +00:00
}
psftp now works as part of the PuTTY suite [originally from svn r940]
2001-02-24 16:08:56 +00:00
/* Set username */
if (user != NULL && user[0] != '\0') {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
conf_set_str(conf, CONF_username, user);
psftp now works as part of the PuTTY suite [originally from svn r940]
2001-02-24 16:08:56 +00:00
}
if (portnumber)
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
conf_set_int(conf, CONF_port, portnumber);
psftp now works as part of the PuTTY suite [originally from svn r940]
2001-02-24 16:08:56 +00:00
psftp and pscp should disable all forwarding (ports, X, agent). Partly because that's a good idea _anyway_, and partly because it seems to be causing trouble. (Specifically, their pathetic attempt to emulate plink's proper select handling seems to get confused when the back end tries to open a local listening socket.) [originally from svn r1264]
2001-09-12 20:11:48 +00:00
/*
* Disable scary things which shouldn't be enabled for simple
* things like SCP and SFTP: agent forwarding, port forwarding,
* X forwarding.
*/
Switch some Conf settings over to being bool. I think this is the full set of things that ought logically to be boolean. One annoyance is that quite a few radio-button controls in config.c address Conf fields that are now bool rather than int, which means that the shared handler function can't just access them all with conf_{get,set}_int. Rather than back out the rigorous separation of int and bool in conf.c itself, I've just added a similar alternative handler function for the bool-typed ones.
2018-10-29 19:57:31 +00:00
conf_set_bool(conf, CONF_x11_forward, false);
conf_set_bool(conf, CONF_agentfwd, false);
conf_set_bool(conf, CONF_ssh_simple, true);
Post-release destabilisation! Completely remove the struct type 'Config' in putty.h, which stores all PuTTY's settings and includes an arbitrary length limit on every single one of those settings which is stored in string form. In place of it is 'Conf', an opaque data type everywhere outside the new file conf.c, which stores a list of (key, value) pairs in which every key contains an integer identifying a configuration setting, and for some of those integers the key also contains extra parts (so that, for instance, CONF_environmt is a string-to-string mapping). Everywhere that a Config was previously used, a Conf is now; everywhere there was a Config structure copy, conf_copy() is called; every lookup, adjustment, load and save operation on a Config has been rewritten; and there's a mechanism for serialising a Conf into a binary blob and back for use with Duplicate Session. User-visible effects of this change _should_ be minimal, though I don't doubt I've introduced one or two bugs here and there which will eventually be found. The _intended_ visible effects of this change are that all arbitrary limits on configuration strings and lists (e.g. limit on number of port forwardings) should now disappear; that list boxes in the configuration will now be displayed in a sorted order rather than the arbitrary order in which they were added to the list (since the underlying data structure is now a sorted tree234 rather than an ad-hoc comma-separated string); and one more specific change, which is that local and dynamic port forwardings on the same port number are now mutually exclusive in the configuration (putting 'D' in the key rather than the value was a mistake in the first place). One other reorganisation as a result of this is that I've moved all the dialog.c standard handlers (dlg_stdeditbox_handler and friends) out into config.c, because I can't really justify calling them generic any more. When they took a pointer to an arbitrary structure type and the offset of a field within that structure, they were independent of whether that structure was a Config or something completely different, but now they really do expect to talk to a Conf, which can _only_ be used for PuTTY configuration, so I've renamed them all things like conf_editbox_handler and moved them out of the nominally independent dialog-box management module into the PuTTY-specific config.c. [originally from svn r9214]
2011-07-14 18:52:21 +00:00
{
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
char *key;
while ((key = conf_get_str_nthstrkey(conf, CONF_portfwd, 0)) != NULL)
conf_del_str_str(conf, CONF_portfwd, key);
Post-release destabilisation! Completely remove the struct type 'Config' in putty.h, which stores all PuTTY's settings and includes an arbitrary length limit on every single one of those settings which is stored in string form. In place of it is 'Conf', an opaque data type everywhere outside the new file conf.c, which stores a list of (key, value) pairs in which every key contains an integer identifying a configuration setting, and for some of those integers the key also contains extra parts (so that, for instance, CONF_environmt is a string-to-string mapping). Everywhere that a Config was previously used, a Conf is now; everywhere there was a Config structure copy, conf_copy() is called; every lookup, adjustment, load and save operation on a Config has been rewritten; and there's a mechanism for serialising a Conf into a binary blob and back for use with Duplicate Session. User-visible effects of this change _should_ be minimal, though I don't doubt I've introduced one or two bugs here and there which will eventually be found. The _intended_ visible effects of this change are that all arbitrary limits on configuration strings and lists (e.g. limit on number of port forwardings) should now disappear; that list boxes in the configuration will now be displayed in a sorted order rather than the arbitrary order in which they were added to the list (since the underlying data structure is now a sorted tree234 rather than an ad-hoc comma-separated string); and one more specific change, which is that local and dynamic port forwardings on the same port number are now mutually exclusive in the configuration (putting 'D' in the key rather than the value was a mistake in the first place). One other reorganisation as a result of this is that I've moved all the dialog.c standard handlers (dlg_stdeditbox_handler and friends) out into config.c, because I can't really justify calling them generic any more. When they took a pointer to an arbitrary structure type and the offset of a field within that structure, they were independent of whether that structure was a Config or something completely different, but now they really do expect to talk to a Conf, which can _only_ be used for PuTTY configuration, so I've renamed them all things like conf_editbox_handler and moved them out of the nominally independent dialog-box management module into the PuTTY-specific config.c. [originally from svn r9214]
2011-07-14 18:52:21 +00:00
}
psftp and pscp should disable all forwarding (ports, X, agent). Partly because that's a good idea _anyway_, and partly because it seems to be causing trouble. (Specifically, their pathetic attempt to emulate plink's proper select handling seems to get confused when the back end tries to open a local listening socket.) [originally from svn r1264]
2001-09-12 20:11:48 +00:00
PSFTP will now attempt to find /usr/[local]/lib/sftp-server if it can't start the sftp subsystem. This should enable convenient sftp access to SSH1-only systems: all the admin needs is to install sftp-server in the right place. [originally from svn r1228]
2001-09-05 19:48:52 +00:00
/* Set up subsystem name. */
Post-release destabilisation! Completely remove the struct type 'Config' in putty.h, which stores all PuTTY's settings and includes an arbitrary length limit on every single one of those settings which is stored in string form. In place of it is 'Conf', an opaque data type everywhere outside the new file conf.c, which stores a list of (key, value) pairs in which every key contains an integer identifying a configuration setting, and for some of those integers the key also contains extra parts (so that, for instance, CONF_environmt is a string-to-string mapping). Everywhere that a Config was previously used, a Conf is now; everywhere there was a Config structure copy, conf_copy() is called; every lookup, adjustment, load and save operation on a Config has been rewritten; and there's a mechanism for serialising a Conf into a binary blob and back for use with Duplicate Session. User-visible effects of this change _should_ be minimal, though I don't doubt I've introduced one or two bugs here and there which will eventually be found. The _intended_ visible effects of this change are that all arbitrary limits on configuration strings and lists (e.g. limit on number of port forwardings) should now disappear; that list boxes in the configuration will now be displayed in a sorted order rather than the arbitrary order in which they were added to the list (since the underlying data structure is now a sorted tree234 rather than an ad-hoc comma-separated string); and one more specific change, which is that local and dynamic port forwardings on the same port number are now mutually exclusive in the configuration (putting 'D' in the key rather than the value was a mistake in the first place). One other reorganisation as a result of this is that I've moved all the dialog.c standard handlers (dlg_stdeditbox_handler and friends) out into config.c, because I can't really justify calling them generic any more. When they took a pointer to an arbitrary structure type and the offset of a field within that structure, they were independent of whether that structure was a Config or something completely different, but now they really do expect to talk to a Conf, which can _only_ be used for PuTTY configuration, so I've renamed them all things like conf_editbox_handler and moved them out of the nominally independent dialog-box management module into the PuTTY-specific config.c. [originally from svn r9214]
2011-07-14 18:52:21 +00:00
conf_set_str(conf, CONF_remote_cmd, "sftp");
Switch some Conf settings over to being bool. I think this is the full set of things that ought logically to be boolean. One annoyance is that quite a few radio-button controls in config.c address Conf fields that are now bool rather than int, which means that the shared handler function can't just access them all with conf_{get,set}_int. Rather than back out the rigorous separation of int and bool in conf.c itself, I've just added a similar alternative handler function for the bool-typed ones.
2018-10-29 19:57:31 +00:00
conf_set_bool(conf, CONF_ssh_subsys, true);
conf_set_bool(conf, CONF_nopty, true);
psftp now works as part of the PuTTY suite [originally from svn r940]
2001-02-24 16:08:56 +00:00
PSFTP will now attempt to find /usr/[local]/lib/sftp-server if it can't start the sftp subsystem. This should enable convenient sftp access to SSH1-only systems: all the admin needs is to install sftp-server in the right place. [originally from svn r1228]
2001-09-05 19:48:52 +00:00
/*
Consistently use a single notation to refer to SSH protocol versions, as discussed. Use Barrett and Silverman's convention of "SSH-1" for SSH protocol version 1 and "SSH-2" for protocol 2 ("SSH1"/"SSH2" refer to ssh.com implementations in this scheme). <http://www.snailbook.com/terms.html> [originally from svn r5480]
2005-03-10 16:36:05 +00:00
* Set up fallback option, for SSH-1 servers or servers with the
PSFTP will now attempt to find /usr/[local]/lib/sftp-server if it can't start the sftp subsystem. This should enable convenient sftp access to SSH1-only systems: all the admin needs is to install sftp-server in the right place. [originally from svn r1228]
2001-09-05 19:48:52 +00:00
* sftp subsystem not enabled but the server binary installed
* in the usual place. We only support fallback on Unix
Better yet, look for sftp-server on the user's PATH as well, which allows individual users with shell access to install it without reference to the admin. [originally from svn r1229]
2001-09-05 19:58:25 +00:00
* systems, and we use a kludgy piece of shellery which should
* try to find sftp-server in various places (the obvious
* systemwide spots /usr/lib and /usr/local/lib, and then the
* user's PATH) and finally give up.
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
*
Better yet, look for sftp-server on the user's PATH as well, which allows individual users with shell access to install it without reference to the admin. [originally from svn r1229]
2001-09-05 19:58:25 +00:00
* test -x /usr/lib/sftp-server && exec /usr/lib/sftp-server
* test -x /usr/local/lib/sftp-server && exec /usr/local/lib/sftp-server
* exec sftp-server
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
*
PSFTP will now attempt to find /usr/[local]/lib/sftp-server if it can't start the sftp subsystem. This should enable convenient sftp access to SSH1-only systems: all the admin needs is to install sftp-server in the right place. [originally from svn r1228]
2001-09-05 19:48:52 +00:00
* the idea being that this will attempt to use either of the
* obvious pathnames and then give up, and when it does give up
* it will print the preferred pathname in the error messages.
*/
Post-release destabilisation! Completely remove the struct type 'Config' in putty.h, which stores all PuTTY's settings and includes an arbitrary length limit on every single one of those settings which is stored in string form. In place of it is 'Conf', an opaque data type everywhere outside the new file conf.c, which stores a list of (key, value) pairs in which every key contains an integer identifying a configuration setting, and for some of those integers the key also contains extra parts (so that, for instance, CONF_environmt is a string-to-string mapping). Everywhere that a Config was previously used, a Conf is now; everywhere there was a Config structure copy, conf_copy() is called; every lookup, adjustment, load and save operation on a Config has been rewritten; and there's a mechanism for serialising a Conf into a binary blob and back for use with Duplicate Session. User-visible effects of this change _should_ be minimal, though I don't doubt I've introduced one or two bugs here and there which will eventually be found. The _intended_ visible effects of this change are that all arbitrary limits on configuration strings and lists (e.g. limit on number of port forwardings) should now disappear; that list boxes in the configuration will now be displayed in a sorted order rather than the arbitrary order in which they were added to the list (since the underlying data structure is now a sorted tree234 rather than an ad-hoc comma-separated string); and one more specific change, which is that local and dynamic port forwardings on the same port number are now mutually exclusive in the configuration (putting 'D' in the key rather than the value was a mistake in the first place). One other reorganisation as a result of this is that I've moved all the dialog.c standard handlers (dlg_stdeditbox_handler and friends) out into config.c, because I can't really justify calling them generic any more. When they took a pointer to an arbitrary structure type and the offset of a field within that structure, they were independent of whether that structure was a Config or something completely different, but now they really do expect to talk to a Conf, which can _only_ be used for PuTTY configuration, so I've renamed them all things like conf_editbox_handler and moved them out of the nominally independent dialog-box management module into the PuTTY-specific config.c. [originally from svn r9214]
2011-07-14 18:52:21 +00:00
conf_set_str(conf, CONF_remote_cmd2,
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
"test -x /usr/lib/sftp-server &&"
" exec /usr/lib/sftp-server\n"
"test -x /usr/local/lib/sftp-server &&"
" exec /usr/local/lib/sftp-server\n"
"exec sftp-server");
Switch some Conf settings over to being bool. I think this is the full set of things that ought logically to be boolean. One annoyance is that quite a few radio-button controls in config.c address Conf fields that are now bool rather than int, which means that the shared handler function can't just access them all with conf_{get,set}_int. Rather than back out the rigorous separation of int and bool in conf.c itself, I've just added a similar alternative handler function for the bool-typed ones.
2018-10-29 19:57:31 +00:00
conf_set_bool(conf, CONF_ssh_subsys2, false);
PSFTP will now attempt to find /usr/[local]/lib/sftp-server if it can't start the sftp subsystem. This should enable convenient sftp access to SSH1-only systems: all the admin needs is to install sftp-server in the right place. [originally from svn r1228]
2001-09-05 19:48:52 +00:00
Remove FLAG_VERBOSE. The global 'int flags' has always been an ugly feature of this code base, and I suddenly thought that perhaps it's time to start throwing it out, one flag at a time, until it's totally unused. My first target is FLAG_VERBOSE. This was usually set by cmdline.c when it saw a -v option on the program's command line, except that GUI PuTTY itself sets it unconditionally on startup. And then various bits of the code would check it in order to decide whether to print a given message. In the current system of front-end abstraction traits, there's no _one_ place that I can move it to. But there are two: every place that checked FLAG_VERBOSE has access to either a Seat or a LogPolicy. So now each of those traits has a query method for 'do I want verbose messages?'. A good effect of this is that subsidiary Seats, like the ones used in Uppity for the main SSH server module itself and the server end of shell channels, now get to have their own verbosity setting instead of inheriting the one global one. In fact I don't expect any code using those Seats to be generating any messages at all, but if that changes later, we'll have a way to control it. (Who knows, perhaps logging in Uppity might become a thing.) As part of this cleanup, I've added a new flag to cmdline_tooltype, called TOOLTYPE_NO_VERBOSE_OPTION. The unconditionally-verbose tools now set that, and it has the effect of making cmdline.c disallow -v completely. So where 'putty -v' would previously have been silently ignored ("I was already verbose"), it's now an error, reminding you that that option doesn't actually do anything. Finally, the 'default_logpolicy' provided by uxcons.c and wincons.c (with identical definitions) has had to move into a new file of its own, because now it has to ask cmdline.c for the verbosity setting as well as asking console.c for the rest of its methods. So there's a new file clicons.c which can only be included by programs that link against both cmdline.c _and_ one of the *cons.c, and I've renamed the logpolicy to reflect that.
2020-01-30 06:40:21 +00:00
psftp_logctx = log_init(console_cli_logpolicy, conf);
Start logging earlier in PSCP and PSFTP. We were missing log messages about the start of the network connection.
2017-02-11 00:23:36 +00:00
Remove FLAG_VERBOSE. The global 'int flags' has always been an ugly feature of this code base, and I suddenly thought that perhaps it's time to start throwing it out, one flag at a time, until it's totally unused. My first target is FLAG_VERBOSE. This was usually set by cmdline.c when it saw a -v option on the program's command line, except that GUI PuTTY itself sets it unconditionally on startup. And then various bits of the code would check it in order to decide whether to print a given message. In the current system of front-end abstraction traits, there's no _one_ place that I can move it to. But there are two: every place that checked FLAG_VERBOSE has access to either a Seat or a LogPolicy. So now each of those traits has a query method for 'do I want verbose messages?'. A good effect of this is that subsidiary Seats, like the ones used in Uppity for the main SSH server module itself and the server end of shell channels, now get to have their own verbosity setting instead of inheriting the one global one. In fact I don't expect any code using those Seats to be generating any messages at all, but if that changes later, we'll have a way to control it. (Who knows, perhaps logging in Uppity might become a thing.) As part of this cleanup, I've added a new flag to cmdline_tooltype, called TOOLTYPE_NO_VERBOSE_OPTION. The unconditionally-verbose tools now set that, and it has the effect of making cmdline.c disallow -v completely. So where 'putty -v' would previously have been silently ignored ("I was already verbose"), it's now an error, reminding you that that option doesn't actually do anything. Finally, the 'default_logpolicy' provided by uxcons.c and wincons.c (with identical definitions) has had to move into a new file of its own, because now it has to ask cmdline.c for the verbosity setting as well as asking console.c for the rest of its methods. So there's a new file clicons.c which can only be included by programs that link against both cmdline.c _and_ one of the *cons.c, and I've renamed the logpolicy to reflect that.
2020-01-30 06:40:21 +00:00
platform_psftp_pre_conn_setup(console_cli_logpolicy);
Log when -restrict-acl is in use. Partly to reassure the user that they got what they asked for, and partly so that's a clue for us in the logs when we get bug reports. This involved repurposing platform_psftp_post_option_setup() (no longer used since e22120fe) as platform_psftp_pre_conn_setup(), and moving it to after logging is set up.
2017-02-11 00:44:00 +00:00
Fix assorted memory leaks. Affects command-line PuTTYgen, PSFTP, and anything running the SSH-2 userauth client layer. Tweaked version of a patch due to Tim Kosse.
2019-07-06 16:44:15 +00:00
err = backend_init(&ssh_backend, psftp_seat, &backend, psftp_logctx, conf,
Turn Backend into a sensible classoid. Nearly every part of the code that ever handles a full backend structure has historically done it using a pair of pointer variables, one pointing at a constant struct full of function pointers, and the other pointing to a 'void *' state object that's passed to each of those. While I'm modernising the rest of the code, this seems like a good time to turn that into the same more or less type-safe and less cumbersome system as I'm using for other parts of the code, such as Socket, Plug, BinaryPacketProtocol and so forth: the Backend structure contains a vtable pointer, and a system of macro wrappers handles dispatching through that vtable.
2018-09-11 15:23:38 +00:00
conf_get_str(conf, CONF_host),
conf_get_int(conf, CONF_port),
&realhost, 0,
Switch some Conf settings over to being bool. I think this is the full set of things that ought logically to be boolean. One annoyance is that quite a few radio-button controls in config.c address Conf fields that are now bool rather than int, which means that the shared handler function can't just access them all with conf_{get,set}_int. Rather than back out the rigorous separation of int and bool in conf.c itself, I've just added a similar alternative handler function for the bool-typed ones.
2018-10-29 19:57:31 +00:00
conf_get_bool(conf, CONF_tcp_keepalives));
psftp now works as part of the PuTTY suite [originally from svn r940]
2001-02-24 16:08:56 +00:00
if (err != NULL) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
fprintf(stderr, "ssh_init: %s\n", err);
return 1;
psftp now works as part of the PuTTY suite [originally from svn r940]
2001-02-24 16:08:56 +00:00
}
Turn Backend into a sensible classoid. Nearly every part of the code that ever handles a full backend structure has historically done it using a pair of pointer variables, one pointing at a constant struct full of function pointers, and the other pointing to a 'void *' state object that's passed to each of those. While I'm modernising the rest of the code, this seems like a good time to turn that into the same more or less type-safe and less cumbersome system as I'm using for other parts of the code, such as Socket, Plug, BinaryPacketProtocol and so forth: the Backend structure contains a vtable pointer, and a system of macro wrappers handles dispatching through that vtable.
2018-09-11 15:23:38 +00:00
while (!backend_sendok(backend)) {
if (backend_exitcode(backend) >= 0)
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
return 1;
if (ssh_sftp_loop_iteration() < 0) {
fprintf(stderr, "ssh_init: error during SSH connection setup\n");
return 1;
}
Next phase of general SFTP reworking: psftp.c is now a platform- independent source file. All Windowsisms have been moved out to winsftp.c. [originally from svn r3418]
2003-08-24 12:47:46 +00:00
}
psftp now works as part of the PuTTY suite [originally from svn r940]
2001-02-24 16:08:56 +00:00
if (verbose && realhost != NULL)
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
printf("Connected to %s\n", realhost);
Joe Yates's memory leak patches. [originally from svn r3650]
2003-12-19 12:44:46 +00:00
if (realhost != NULL)
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
sfree(realhost);
Allow PSFTP to be run with no arguments, in which case it enters the command-line state but all commands are disallowed except `open host.name'. The idea is to provide marginal extra niceness for people who double-click the icon without realising it's a cmdline app. [originally from svn r1480]
2001-12-13 18:42:34 +00:00
return 0;
}
Giant const-correctness patch of doom! Having found a lot of unfixed constness issues in recent development, I thought perhaps it was time to get proactive, so I compiled the whole codebase with -Wwrite-strings. That turned up a huge load of const problems, which I've fixed in this commit: the Unix build now goes cleanly through with -Wwrite-strings, and the Windows build is as close as I could get it (there are some lingering issues due to occasional Windows API functions like AcquireCredentialsHandle not having the right constness). Notable fallout beyond the purely mechanical changing of types: - the stuff saved by cmdline_save_param() is now explicitly dupstr()ed, and freed in cmdline_run_saved. - I couldn't make both string arguments to cmdline_process_param() const, because it intentionally writes to one of them in the case where it's the argument to -pw (in the vain hope of being at least slightly friendly to 'ps'), so elsewhere I had to temporarily dupstr() something for the sake of passing it to that function - I had to invent a silly parallel version of const_cmp() so I could pass const string literals in to lookup functions. - stripslashes() in pscp.c and psftp.c has the annoying strchr nature
2015-05-15 10:15:42 +00:00
void cmdline_error(const char *p, ...)
Revamp of command-line handling. Most command line options should now be processed in cmdline.c, which is called from all utilities (well, not Pageant or PuTTYgen). This should mean we get to standardise almost all options across almost all tools. Also one major change: `-load' is now the preferred option for loading a saved session in PuTTY proper. `@session' still works but is deprecated. [originally from svn r1799]
2002-08-04 21:18:56 +00:00
{
va_list ap;
Fixes for more robust handling of command-line parse errors. [originally from svn r2236]
2002-11-20 20:09:02 +00:00
fprintf(stderr, "psftp: ");
Revamp of command-line handling. Most command line options should now be processed in cmdline.c, which is called from all utilities (well, not Pageant or PuTTYgen). This should mean we get to standardise almost all options across almost all tools. Also one major change: `-load' is now the preferred option for loading a saved session in PuTTY proper. `@session' still works but is deprecated. [originally from svn r1799]
2002-08-04 21:18:56 +00:00
va_start(ap, p);
vfprintf(stderr, p, ap);
va_end(ap);
Fixes for more robust handling of command-line parse errors. [originally from svn r2236]
2002-11-20 20:09:02 +00:00
fprintf(stderr, "\n try typing \"psftp -h\" for help\n");
Revamp of command-line handling. Most command line options should now be processed in cmdline.c, which is called from all utilities (well, not Pageant or PuTTYgen). This should mean we get to standardise almost all options across almost all tools. Also one major change: `-load' is now the preferred option for loading a saved session in PuTTY proper. `@session' still works but is deprecated. [originally from svn r1799]
2002-08-04 21:18:56 +00:00
exit(1);
}
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
const bool share_can_be_downstream = true;
const bool share_can_be_upstream = false;
Implement connection sharing between instances of PuTTY. The basic strategy is described at the top of the new source file sshshare.c. In very brief: an 'upstream' PuTTY opens a Unix-domain socket or Windows named pipe, and listens for connections from other PuTTYs wanting to run sessions on the same server. The protocol spoken down that socket/pipe is essentially the bare ssh-connection protocol, using a trivial binary packet protocol with no encryption, and the upstream has to do some fiddly transformations that I've been referring to as 'channel-number NAT' to avoid resource clashes between the sessions it's managing. This is quite different from OpenSSH's approach of using the Unix- domain socket as a means of passing file descriptors around; the main reason for that is that fd-passing is Unix-specific but this system has to work on Windows too. However, there are additional advantages, such as making it easy for each downstream PuTTY to run its own independent set of port and X11 forwardings (though the method for making the latter work is quite painful). Sharing is off by default, but configuration is intended to be very easy in the normal case - just tick one box in the SSH config panel and everything else happens automatically. [originally from svn r10083]
2013-11-17 14:05:41 +00:00
File transfer tools: sanitise remote filenames and stderr. This commit adds sanitisation to PSCP and PSFTP in the same style as I've just put it into Plink. This time, standard error is sanitised without reference to whether it's redirected (at least unless you give an override option), on the basis that where Plink is _sometimes_ an SSH transport for some other protocol, PSCP and PSFTP _always_ are. But also, the sanitiser is run over any remote filename sent by the server, substituting ? for any control characters it finds. That removes another avenue for the server to deliberately confuse the display. This commit fixes our bug 'pscp-unsanitised-server-output', aka the two notional 'vulnerabilities' CVE-2019-6109 and CVE-2019-6110. (Although we regard those in isolation as only bugs, not serious vulnerabilities, because their main threat was in hiding the evidence of a server having exploited other more serious vulns that we never had.)
2019-02-20 07:09:10 +00:00
static stdio_sink stderr_ss;
static StripCtrlChars *stderr_scc;
Make cmdline_tooltype a const int. Another ugly mutable global variable gone: now, instead of this variable being defined in cmdline.c and written to by everyone's main(), it's defined _alongside_ everyone's main() as a constant, and cmdline.c just refers to it. A bonus is that now nocmdline.c doesn't have to define it anyway for tools that don't use cmdline.c. But mostly, it didn't need to be mutable, so better for it not to be. While I'm at it, I've also fiddled with the bit flags that go in it, to define their values automatically using a list macro instead of manually specifying each one to be a different power of 2.
2020-01-30 06:40:22 +00:00
const unsigned cmdline_tooltype = TOOLTYPE_FILETRANSFER;
Allow PSFTP to be run with no arguments, in which case it enters the command-line state but all commands are disallowed except `open host.name'. The idea is to provide marginal extra niceness for people who double-click the icon without realising it's a cmdline app. [originally from svn r1480]
2001-12-13 18:42:34 +00:00
/*
* Main program. Parse arguments etc.
*/
Next phase of general SFTP reworking: psftp.c is now a platform- independent source file. All Windowsisms have been moved out to winsftp.c. [originally from svn r3418]
2003-08-24 12:47:46 +00:00
int psftp_main(int argc, char *argv[])
Allow PSFTP to be run with no arguments, in which case it enters the command-line state but all commands are disallowed except `open host.name'. The idea is to provide marginal extra niceness for people who double-click the icon without realising it's a cmdline app. [originally from svn r1480]
2001-12-13 18:42:34 +00:00
{
When PSFTP exits in batch mode due to a command failure, set exit status != 0. There are possibly other circumstances when PSFTP should also return failure, but that one seems particularly obvious.
2015-06-25 22:27:16 +00:00
int i, ret;
Allow PSFTP to be run with no arguments, in which case it enters the command-line state but all commands are disallowed except `open host.name'. The idea is to provide marginal extra niceness for people who double-click the icon without realising it's a cmdline app. [originally from svn r1480]
2001-12-13 18:42:34 +00:00
int portnumber = 0;
char *userhost, *user;
int mode = 0;
int modeflags = 0;
File transfer tools: sanitise remote filenames and stderr. This commit adds sanitisation to PSCP and PSFTP in the same style as I've just put it into Plink. This time, standard error is sanitised without reference to whether it's redirected (at least unless you give an override option), on the basis that where Plink is _sometimes_ an SSH transport for some other protocol, PSCP and PSFTP _always_ are. But also, the sanitiser is run over any remote filename sent by the server, substituting ? for any control characters it finds. That removes another avenue for the server to deliberately confuse the display. This commit fixes our bug 'pscp-unsanitised-server-output', aka the two notional 'vulnerabilities' CVE-2019-6109 and CVE-2019-6110. (Although we regard those in isolation as only bugs, not serious vulnerabilities, because their main threat was in hiding the evidence of a server having exploited other more serious vulns that we never had.)
2019-02-20 07:09:10 +00:00
bool sanitise_stderr = true;
Allow PSFTP to be run with no arguments, in which case it enters the command-line state but all commands are disallowed except `open host.name'. The idea is to provide marginal extra niceness for people who double-click the icon without realising it's a cmdline app. [originally from svn r1480]
2001-12-13 18:42:34 +00:00
char *batchfile = NULL;
sk_init();
userhost = user = NULL;
Fix for `psftp-pscp-ignore-load': Default Settings is now loaded before "-load" is processed so that it doesn't clobber it. I've also changed the semantics of "-load" slightly for PSCP, PSFTP, and Plink: if it's specified at all, it overrides (disables) the implicit loading of session details based on a supplied hostname elsewhere (on the grounds that the user is more likely to want the "-load" session than the implicit session). (PuTTY itself doesn't do implicit loading at all, so I haven't changed it.) This means that all the PuTTY tools' behaviour is now consistent iff "-load" is specified (otherwise, some tools have implicit-session, and others don't). However, I've not documented this behaviour, as there's a good chance it will be swept away if and when we get round to sorting out how we deal with settings from multiple sources. It's intended as a "do something sensible" change. [originally from svn r4352]
2004-07-25 14:00:26 +00:00
/* Load Default Settings before doing anything else. */
Post-release destabilisation! Completely remove the struct type 'Config' in putty.h, which stores all PuTTY's settings and includes an arbitrary length limit on every single one of those settings which is stored in string form. In place of it is 'Conf', an opaque data type everywhere outside the new file conf.c, which stores a list of (key, value) pairs in which every key contains an integer identifying a configuration setting, and for some of those integers the key also contains extra parts (so that, for instance, CONF_environmt is a string-to-string mapping). Everywhere that a Config was previously used, a Conf is now; everywhere there was a Config structure copy, conf_copy() is called; every lookup, adjustment, load and save operation on a Config has been rewritten; and there's a mechanism for serialising a Conf into a binary blob and back for use with Duplicate Session. User-visible effects of this change _should_ be minimal, though I don't doubt I've introduced one or two bugs here and there which will eventually be found. The _intended_ visible effects of this change are that all arbitrary limits on configuration strings and lists (e.g. limit on number of port forwardings) should now disappear; that list boxes in the configuration will now be displayed in a sorted order rather than the arbitrary order in which they were added to the list (since the underlying data structure is now a sorted tree234 rather than an ad-hoc comma-separated string); and one more specific change, which is that local and dynamic port forwardings on the same port number are now mutually exclusive in the configuration (putting 'D' in the key rather than the value was a mistake in the first place). One other reorganisation as a result of this is that I've moved all the dialog.c standard handlers (dlg_stdeditbox_handler and friends) out into config.c, because I can't really justify calling them generic any more. When they took a pointer to an arbitrary structure type and the offset of a field within that structure, they were independent of whether that structure was a Config or something completely different, but now they really do expect to talk to a Conf, which can _only_ be used for PuTTY configuration, so I've renamed them all things like conf_editbox_handler and moved them out of the nominally independent dialog-box management module into the PuTTY-specific config.c. [originally from svn r9214]
2011-07-14 18:52:21 +00:00
conf = conf_new();
do_defaults(NULL, conf);
Fix for `psftp-pscp-ignore-load': Default Settings is now loaded before "-load" is processed so that it doesn't clobber it. I've also changed the semantics of "-load" slightly for PSCP, PSFTP, and Plink: if it's specified at all, it overrides (disables) the implicit loading of session details based on a supplied hostname elsewhere (on the grounds that the user is more likely to want the "-load" session than the implicit session). (PuTTY itself doesn't do implicit loading at all, so I haven't changed it.) This means that all the PuTTY tools' behaviour is now consistent iff "-load" is specified (otherwise, some tools have implicit-session, and others don't). However, I've not documented this behaviour, as there's a good chance it will be swept away if and when we get round to sorting out how we deal with settings from multiple sources. It's intended as a "do something sensible" change. [originally from svn r4352]
2004-07-25 14:00:26 +00:00
Allow PSFTP to be run with no arguments, in which case it enters the command-line state but all commands are disallowed except `open host.name'. The idea is to provide marginal extra niceness for people who double-click the icon without realising it's a cmdline app. [originally from svn r1480]
2001-12-13 18:42:34 +00:00
for (i = 1; i < argc; i++) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
int ret;
if (argv[i][0] != '-') {
Revamp of command-line handling. Most command line options should now be processed in cmdline.c, which is called from all utilities (well, not Pageant or PuTTYgen). This should mean we get to standardise almost all options across almost all tools. Also one major change: `-load' is now the preferred option for loading a saved session in PuTTY proper. `@session' still works but is deprecated. [originally from svn r1799]
2002-08-04 21:18:56 +00:00
if (userhost)
usage();
else
userhost = dupstr(argv[i]);
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
continue;
}
ret = cmdline_process_param(argv[i], i+1<argc?argv[i+1]:NULL, 1, conf);
if (ret == -2) {
cmdline_error("option \"%s\" requires an argument", argv[i]);
} else if (ret == 2) {
i++; /* skip next argument */
} else if (ret == 1) {
/* We have our own verbosity in addition to `flags'. */
Remove FLAG_VERBOSE. The global 'int flags' has always been an ugly feature of this code base, and I suddenly thought that perhaps it's time to start throwing it out, one flag at a time, until it's totally unused. My first target is FLAG_VERBOSE. This was usually set by cmdline.c when it saw a -v option on the program's command line, except that GUI PuTTY itself sets it unconditionally on startup. And then various bits of the code would check it in order to decide whether to print a given message. In the current system of front-end abstraction traits, there's no _one_ place that I can move it to. But there are two: every place that checked FLAG_VERBOSE has access to either a Seat or a LogPolicy. So now each of those traits has a query method for 'do I want verbose messages?'. A good effect of this is that subsidiary Seats, like the ones used in Uppity for the main SSH server module itself and the server end of shell channels, now get to have their own verbosity setting instead of inheriting the one global one. In fact I don't expect any code using those Seats to be generating any messages at all, but if that changes later, we'll have a way to control it. (Who knows, perhaps logging in Uppity might become a thing.) As part of this cleanup, I've added a new flag to cmdline_tooltype, called TOOLTYPE_NO_VERBOSE_OPTION. The unconditionally-verbose tools now set that, and it has the effect of making cmdline.c disallow -v completely. So where 'putty -v' would previously have been silently ignored ("I was already verbose"), it's now an error, reminding you that that option doesn't actually do anything. Finally, the 'default_logpolicy' provided by uxcons.c and wincons.c (with identical definitions) has had to move into a new file of its own, because now it has to ask cmdline.c for the verbosity setting as well as asking console.c for the rest of its methods. So there's a new file clicons.c which can only be included by programs that link against both cmdline.c _and_ one of the *cons.c, and I've renamed the logpolicy to reflect that.
2020-01-30 06:40:21 +00:00
if (cmdline_verbose())
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
verbose = true;
} else if (strcmp(argv[i], "-h") == 0 ||
strcmp(argv[i], "-?") == 0 ||
Make --help and --version work consistently across all tools. Well, at least across all command-line tools on both Windows and Unix, and the GTK apps on Unix too. The Windows GUI apps fundamentally can't write to standard output and it doesn't seem sensible to use message boxes for these purposes :-) [originally from svn r9673]
2012-09-19 17:08:15 +00:00
strcmp(argv[i], "--help") == 0) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
usage();
Try to make our PGP signing more useful: * All the PuTTY tools for Windows and Unix now contain the fingerprints of the Master Keys. The method for accessing them is crude but universal: a new "-pgpfp" command-line option. (Except Unix PuTTYgen, which takes "--pgpfp" just to be awkward.) * Move the key policy discussion from putty-website/keys.html to putty/doc/pgpkeys.but, and autogenerate the former from the latter. Also tweak the text somewhat and include the fingerprints of the Master Keys themselves. (I've merged the existing autogeneration scripts into a single new one; I've left the old scripts and keys.html around until such time as the webmonster reviews the changes and plumbs in the new script; he should remove the old files then.) [originally from svn r5524] [this svn revision also touched putty-website]
2005-03-19 02:26:58 +00:00
} else if (strcmp(argv[i], "-pgpfp") == 0) {
pgp_fingerprints();
return 1;
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
} else if (strcmp(argv[i], "-V") == 0 ||
Make --help and --version work consistently across all tools. Well, at least across all command-line tools on both Windows and Unix, and the GTK apps on Unix too. The Windows GUI apps fundamentally can't write to standard output and it doesn't seem sensible to use message boxes for these purposes :-) [originally from svn r9673]
2012-09-19 17:08:15 +00:00
strcmp(argv[i], "--version") == 0) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
version();
} else if (strcmp(argv[i], "-batch") == 0) {
console_batch_mode = true;
} else if (strcmp(argv[i], "-b") == 0 && i + 1 < argc) {
mode = 1;
batchfile = argv[++i];
} else if (strcmp(argv[i], "-bc") == 0) {
modeflags = modeflags | 1;
} else if (strcmp(argv[i], "-be") == 0) {
modeflags = modeflags | 2;
File transfer tools: sanitise remote filenames and stderr. This commit adds sanitisation to PSCP and PSFTP in the same style as I've just put it into Plink. This time, standard error is sanitised without reference to whether it's redirected (at least unless you give an override option), on the basis that where Plink is _sometimes_ an SSH transport for some other protocol, PSCP and PSFTP _always_ are. But also, the sanitiser is run over any remote filename sent by the server, substituting ? for any control characters it finds. That removes another avenue for the server to deliberately confuse the display. This commit fixes our bug 'pscp-unsanitised-server-output', aka the two notional 'vulnerabilities' CVE-2019-6109 and CVE-2019-6110. (Although we regard those in isolation as only bugs, not serious vulnerabilities, because their main threat was in hiding the evidence of a server having exploited other more serious vulns that we never had.)
2019-02-20 07:09:10 +00:00
} else if (strcmp(argv[i], "-sanitise-stderr") == 0) {
sanitise_stderr = true;
} else if (strcmp(argv[i], "-no-sanitise-stderr") == 0) {
sanitise_stderr = false;
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
} else if (strcmp(argv[i], "--") == 0) {
i++;
break;
} else {
cmdline_error("unknown option \"%s\"", argv[i]);
}
Allow PSFTP to be run with no arguments, in which case it enters the command-line state but all commands are disallowed except `open host.name'. The idea is to provide marginal extra niceness for people who double-click the icon without realising it's a cmdline app. [originally from svn r1480]
2001-12-13 18:42:34 +00:00
}
argc -= i;
argv += i;
Turn Backend into a sensible classoid. Nearly every part of the code that ever handles a full backend structure has historically done it using a pair of pointer variables, one pointing at a constant struct full of function pointers, and the other pointing to a 'void *' state object that's passed to each of those. While I'm modernising the rest of the code, this seems like a good time to turn that into the same more or less type-safe and less cumbersome system as I'm using for other parts of the code, such as Socket, Plug, BinaryPacketProtocol and so forth: the Backend structure contains a vtable pointer, and a system of macro wrappers handles dispatching through that vtable.
2018-09-11 15:23:38 +00:00
backend = NULL;
Allow PSFTP to be run with no arguments, in which case it enters the command-line state but all commands are disallowed except `open host.name'. The idea is to provide marginal extra niceness for people who double-click the icon without realising it's a cmdline app. [originally from svn r1480]
2001-12-13 18:42:34 +00:00
File transfer tools: sanitise remote filenames and stderr. This commit adds sanitisation to PSCP and PSFTP in the same style as I've just put it into Plink. This time, standard error is sanitised without reference to whether it's redirected (at least unless you give an override option), on the basis that where Plink is _sometimes_ an SSH transport for some other protocol, PSCP and PSFTP _always_ are. But also, the sanitiser is run over any remote filename sent by the server, substituting ? for any control characters it finds. That removes another avenue for the server to deliberately confuse the display. This commit fixes our bug 'pscp-unsanitised-server-output', aka the two notional 'vulnerabilities' CVE-2019-6109 and CVE-2019-6110. (Although we regard those in isolation as only bugs, not serious vulnerabilities, because their main threat was in hiding the evidence of a server having exploited other more serious vulns that we never had.)
2019-02-20 07:09:10 +00:00
stdio_sink_init(&stderr_ss, stderr);
stderr_bs = BinarySink_UPCAST(&stderr_ss);
if (sanitise_stderr) {
stderr_scc = stripctrl_new(stderr_bs, false, L'\0');
stderr_bs = BinarySink_UPCAST(stderr_scc);
}
Make stripctrl_string take an existing StripCtrlChars. Now instead of making a StripCtrlChars just for that function call, it uses an existing one, pointing it at the output strbuf via stripctrl_retarget. This adds flexibility (now you can use the same convenient string- sanitising function with a StripCtrl configured in any way you like) and also saves pointless setting-up and tearing-down of identical sccs all the time. The existing call sites in PSCP and PSFTP now use a static StripCtrlChars instance that was made at program startup.
2019-03-09 16:03:40 +00:00
string_scc = stripctrl_new(NULL, false, L'\0');
Another wart in the command-line processing: if the user just specifies `-load sessname', and that mentions a hostname, that should be sufficient to start a connection. [originally from svn r4369]
2004-07-28 11:04:22 +00:00
/*
* If the loaded session provides a hostname, and a hostname has not
* otherwise been specified, pop it in `userhost' so that
* `psftp -load sessname' is sufficient to start a session.
*/
Post-release destabilisation! Completely remove the struct type 'Config' in putty.h, which stores all PuTTY's settings and includes an arbitrary length limit on every single one of those settings which is stored in string form. In place of it is 'Conf', an opaque data type everywhere outside the new file conf.c, which stores a list of (key, value) pairs in which every key contains an integer identifying a configuration setting, and for some of those integers the key also contains extra parts (so that, for instance, CONF_environmt is a string-to-string mapping). Everywhere that a Config was previously used, a Conf is now; everywhere there was a Config structure copy, conf_copy() is called; every lookup, adjustment, load and save operation on a Config has been rewritten; and there's a mechanism for serialising a Conf into a binary blob and back for use with Duplicate Session. User-visible effects of this change _should_ be minimal, though I don't doubt I've introduced one or two bugs here and there which will eventually be found. The _intended_ visible effects of this change are that all arbitrary limits on configuration strings and lists (e.g. limit on number of port forwardings) should now disappear; that list boxes in the configuration will now be displayed in a sorted order rather than the arbitrary order in which they were added to the list (since the underlying data structure is now a sorted tree234 rather than an ad-hoc comma-separated string); and one more specific change, which is that local and dynamic port forwardings on the same port number are now mutually exclusive in the configuration (putting 'D' in the key rather than the value was a mistake in the first place). One other reorganisation as a result of this is that I've moved all the dialog.c standard handlers (dlg_stdeditbox_handler and friends) out into config.c, because I can't really justify calling them generic any more. When they took a pointer to an arbitrary structure type and the offset of a field within that structure, they were independent of whether that structure was a Config or something completely different, but now they really do expect to talk to a Conf, which can _only_ be used for PuTTY configuration, so I've renamed them all things like conf_editbox_handler and moved them out of the nominally independent dialog-box management module into the PuTTY-specific config.c. [originally from svn r9214]
2011-07-14 18:52:21 +00:00
if (!userhost && conf_get_str(conf, CONF_host)[0] != '\0') {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
userhost = dupstr(conf_get_str(conf, CONF_host));
Another wart in the command-line processing: if the user just specifies `-load sessname', and that mentions a hostname, that should be sufficient to start a connection. [originally from svn r4369]
2004-07-28 11:04:22 +00:00
}
Allow PSFTP to be run with no arguments, in which case it enters the command-line state but all commands are disallowed except `open host.name'. The idea is to provide marginal extra niceness for people who double-click the icon without realising it's a cmdline app. [originally from svn r1480]
2001-12-13 18:42:34 +00:00
/*
* If a user@host string has already been provided, connect to
* it now.
*/
if (userhost) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
int ret;
ret = psftp_connect(userhost, user, portnumber);
sfree(userhost);
if (ret)
return 1;
if (do_sftp_init())
return 1;
Allow PSFTP to be run with no arguments, in which case it enters the command-line state but all commands are disallowed except `open host.name'. The idea is to provide marginal extra niceness for people who double-click the icon without realising it's a cmdline app. [originally from svn r1480]
2001-12-13 18:42:34 +00:00
} else {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
printf("psftp: no hostname specified; use \"open host.name\""
" to connect\n");
Allow PSFTP to be run with no arguments, in which case it enters the command-line state but all commands are disallowed except `open host.name'. The idea is to provide marginal extra niceness for people who double-click the icon without realising it's a cmdline app. [originally from svn r1480]
2001-12-13 18:42:34 +00:00
}
First stab at an SFTP client. Currently a Unixland testing app, not integrated into PuTTY. [originally from svn r938]
2001-02-23 18:21:44 +00:00
When PSFTP exits in batch mode due to a command failure, set exit status != 0. There are possibly other circumstances when PSFTP should also return failure, but that one seems particularly obvious.
2015-06-25 22:27:16 +00:00
ret = do_sftp(mode, modeflags, batchfile);
psftp now works as part of the PuTTY suite [originally from svn r940]
2001-02-24 16:08:56 +00:00
Turn Backend into a sensible classoid. Nearly every part of the code that ever handles a full backend structure has historically done it using a pair of pointer variables, one pointing at a constant struct full of function pointers, and the other pointing to a 'void *' state object that's passed to each of those. While I'm modernising the rest of the code, this seems like a good time to turn that into the same more or less type-safe and less cumbersome system as I'm using for other parts of the code, such as Socket, Plug, BinaryPacketProtocol and so forth: the Backend structure contains a vtable pointer, and a system of macro wrappers handles dispatching through that vtable.
2018-09-11 15:23:38 +00:00
if (backend && backend_connected(backend)) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
char ch;
Rework special-commands system to add an integer argument. In order to list cross-certifiable host keys in the GUI specials menu, the SSH backend has been inventing new values on the end of the Telnet_Special enumeration, starting from the value TS_LOCALSTART. This is inelegant, and also makes it awkward to break up special handlers (e.g. to dispatch different specials to different SSH layers), since if all you know about a special is that it's somewhere in the TS_LOCALSTART+n space, you can't tell what _general kind_ of thing it is. Also, if I ever need another open-ended set of specials in future, I'll have to remember which TS_LOCALSTART+n codes are in which set. So here's a revamp that causes every special to take an extra integer argument. For all previously numbered specials, this argument is passed as zero and ignored, but there's a new main special code for SSH host key cross-certification, in which the integer argument is an index into the backend's list of available keys. TS_LOCALSTART is now a thing of the past: if I need any other open-ended sets of specials in future, I can add a new top-level code with a nicely separated space of arguments. While I'm at it, I've removed the legacy misnomer 'Telnet_Special' from the code completely; the enum is now SessionSpecialCode, the struct containing full details of a menu entry is SessionSpecial, and the enum values now start SS_ rather than TS_.
2018-09-24 08:35:52 +00:00
backend_special(backend, SS_EOF, 0);
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
sent_eof = true;
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
sftp_recvdata(&ch, 1);
psftp now works as part of the PuTTY suite [originally from svn r940]
2001-02-24 16:08:56 +00:00
}
Implement the `close' command, which terminates an SFTP session but does not quit PSFTP, so you can then issue another `open' to connect to somewhere else. This has apparently been trivial for some time, for exactly the same reasons that `reuse-windows' was so easy, but it hadn't occurred to me to actually do it until now. [originally from svn r4994]
2004-12-16 19:19:59 +00:00
do_sftp_cleanup();
psftp now works as part of the PuTTY suite [originally from svn r940]
2001-02-24 16:08:56 +00:00
random_save_seed();
Joe Yates's memory leak patches. [originally from svn r3650]
2003-12-19 12:44:46 +00:00
cmdline_cleanup();
sk_cleanup();
psftp now works as part of the PuTTY suite [originally from svn r940]
2001-02-24 16:08:56 +00:00
Fix assorted memory leaks. Affects command-line PuTTYgen, PSFTP, and anything running the SSH-2 userauth client layer. Tweaked version of a patch due to Tim Kosse.
2019-07-06 16:44:15 +00:00
stripctrl_free(string_scc);
stripctrl_free(stderr_scc);
if (psftp_logctx)
log_free(psftp_logctx);
When PSFTP exits in batch mode due to a command failure, set exit status != 0. There are possibly other circumstances when PSFTP should also return failure, but that one seems particularly obvious.
2015-06-25 22:27:16 +00:00
return ret;
First stab at an SFTP client. Currently a Unixland testing app, not integrated into PuTTY. [originally from svn r938]
2001-02-23 18:21:44 +00:00
}
Reference in New Issue Copy Permalink