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

2872 lines
73 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
#define PUTTY_DO_GLOBALS
#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.
*/
char *pwd, *homedir;
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;
Remove 'static' qualifier from Conf pointer Configuration pointer is globally visible from winstuff.h, so it cannot be 'static' any longer.
2018-11-03 18:20:40 +00:00
Conf *conf;
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 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.
*/
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 int psftp_output(Seat *, bool is_stderr, const void *, int);
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,
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 }};
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] == '/') {
fullname = dupstr(name);
} else {
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 *slash;
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
if (pwd[strlen(pwd) - 1] == '/')
psftp now works as part of the PuTTY suite [originally from svn r940]
2001-02-24 16:08:56 +00:00
slash = "";
else
slash = "/";
fullname = dupcat(pwd, slash, name, NULL);
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) {
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 {
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
/*
* 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) {
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("/");
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
} else {
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);
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
}
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);
canonname = fxp_realpath_recv(pktin, req);
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
Spotted by Tim Kosse: we were returning an incorrect path in canonify() when we couldn't get any sense out of the server. [originally from svn r6877]
2006-10-22 20:19:55 +00:00
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;
}
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
/*
* We have a canonical name for all but the last path
* component. Concatenate the last component and return.
*/
returnname = dupcat(canonname,
canonname[strlen(canonname) - 1] ==
'/' ? "" : "/", fullname + i + 1, NULL);
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
* qsort comparison routine for fxp_name structures. Sorts by real
* file name.
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 sftp_name_compare(const void *av, const void *bv)
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
{
Fix major memory leak in sftp_cmd_ls (thanks to Hans-Juergen Petrich for pointing it out). [originally from svn r1612]
2002-03-31 16:26:13 +00:00
const struct fxp_name *const *a = (const struct fxp_name *const *) av;
const struct fxp_name *const *b = (const struct fxp_name *const *) bv;
return strcmp((*a)->filename, (*b)->filename);
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
}
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
* Likewise, but for a bare char *.
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
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) {
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;
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);
result = fxp_stat_recv(pktin, req, &attrs);
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
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 (result &&
(attrs.flags & SSH_FILEXFER_ATTR_PERMISSIONS) &&
(attrs.permissions & 0040000)) {
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 fxp_handle *dirhandle;
int nnames, namesize;
struct fxp_name **ournames;
struct fxp_names *names;
int i;
/*
* First, attempt to create the destination directory,
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
* unless it already exists.
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
if (file_type(outfname) != FILE_TYPE_DIRECTORY &&
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
!create_directory(outfname)) {
printf("%s: Cannot create directory\n", 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
return 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
}
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
/*
* 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);
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
if (!dirhandle) {
printf("%s: unable to open directory: %s\n",
fname, 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
return 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
}
nnames = namesize = 0;
ournames = NULL;
while (1) {
int 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_readdir_send(dirhandle);
pktin = sftp_wait_for_reply(req);
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
if (names == NULL) {
if (fxp_error_type() == SSH_FX_EOF)
break;
printf("%s: reading directory: %s\n", fname, 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);
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(ournames);
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 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
}
if (names->nnames == 0) {
fxp_free_names(names);
break;
}
if (nnames + names->nnames >= namesize) {
namesize += names->nnames + 128;
ournames = sresize(ournames, namesize, struct fxp_name *);
}
for (i = 0; i < names->nnames; i++)
General mechanism for ensuring a dodgy SFTP server can't return malicious filenames via FXP_READDIR. [originally from svn r4995]
2004-12-16 19:36:47 +00:00
if (strcmp(names->names[i].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
strcmp(names->names[i].filename, "..")) {
General mechanism for ensuring a dodgy SFTP server can't return malicious filenames via FXP_READDIR. [originally from svn r4995]
2004-12-16 19:36:47 +00:00
if (!vet_filename(names->names[i].filename)) {
printf("ignoring potentially dangerous server-"
"supplied filename '%s'\n",
names->names[i].filename);
} else {
ournames[nnames++] =
fxp_dup_name(&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
fxp_free_names(names);
}
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(dirhandle);
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
/*
* 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
/*
* 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
/*
* 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;
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
nextfname = dupcat(fname, "/", ournames[i]->filename, NULL);
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
retd = sftp_get_file(
nextfname, nextoutfname, recurse, restart);
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
restart = false; /* after first partial file, do full */
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(nextoutfname);
sfree(nextfname);
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) {
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
for (i = 0; i < nnames; i++) {
fxp_free_name(ournames[i]);
}
sfree(ournames);
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 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
}
}
/*
* Done this recursion level. Free everything.
*/
for (i = 0; i < nnames; i++) {
fxp_free_name(ournames[i]);
}
sfree(ournames);
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;
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
}
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) {
Everywhere we print an fxp_error(), try to make it clear what we were trying to do at the time. (A lot of these say just "canonify:". This isn't a nice thing to show to a user, but I don't believe canonify() will ever return failure due to a server error, so users shouldn't actually see it, and it means we have a chance of tracing it if reported.) [originally from svn r6636]
2006-04-13 21:18:09 +00:00
printf("%s: open for read: %s\n", fname, 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
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) {
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
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 {
Add an SFTP server to the SSH server code. Unlike the traditional Unix SSH server organisation, the SFTP server is built into the same process as all the rest of the code. sesschan.c spots a subsystem request for "sftp", and responds to it by instantiating an SftpServer object and swapping out its own vtable for one that talks to it. (I rather like the idea of an object swapping its own vtable for a different one in the middle of its lifetime! This is one of those tricks that would be absurdly hard to implement in a 'proper' OO language, but when you're doing vtables by hand in C, it's no more difficult than any other piece of ordinary pointer manipulation. As long as the methods in both vtables expect the same physical structure layout, it doesn't cause a problem.) The SftpServer object doesn't deal directly with SFTP packet formats; it implements the SFTP server logic in a more abstract way, by having a vtable method for each SFTP request type with an appropriate parameter list. It sends its replies by calling methods in another vtable called SftpReplyBuilder, which in the normal case will write an SFTP reply packet to send back to the client. So SftpServer can focus more or less completely on the details of a particular filesystem API - and hence, the implementation I've got lives in the unix source directory, and works directly with file descriptors and struct stat and the like. (One purpose of this abstraction layer is that I may well want to write a second dummy implementation, for test-suite purposes, with completely controllable behaviour, and now I have a handy place to plug it in in place of the live filesystem.) In between sesschan's parsing of the byte stream into SFTP packets and the SftpServer object, there's a layer in the new file sftpserver.c which does the actual packet decoding and encoding: each request packet is passed to that, which pulls the fields out of the request packet and calls the appropriate method of SftpServer. It also provides the default SftpReplyBuilder which makes the output packet. I've moved some code out of the previous SFTP client implementation - basic packet construction code, and in particular the BinarySink/ BinarySource marshalling fuinction for fxp_attrs - into sftpcommon.c, so that the two directions can share as much as possible.
2018-10-20 21:10:32 +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) {
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
printf("local: unable to open %s\n", outfname);
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 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) {
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
if (seek_file(file, 0, FROM_END) == -1) {
Patch from Tim Kosse to make PSFTP remember to close files on various error conditions. [originally from svn r8109]
2008-07-06 12:11:34 +00:00
close_wfile(file);
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
printf("reget: cannot restart %s - file too large\n",
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
req = fxp_close_send(fh);
pktin = sftp_wait_for_reply(req);
fxp_close_recv(pktin, req);
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
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 false;
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
}
offset = get_file_posn(file);
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
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 {
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("remote:%s => local:%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.
*/
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)) {
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
void *vbuf;
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 retd, len;
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
int wpos, wlen;
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_download_queue(xfer);
pktin = sftp_recv();
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
retd = xfer_download_gotpkt(xfer, pktin);
if (retd <= 0) {
The xfer mechanism wasn't gracefully terminating when an error was encountered part way through transfer. In particular, this caused psftp to hang (waiting for FXP_READ replies which had already arrived) if you try `get' (without -r) on a remote directory. [originally from svn r5005]
2004-12-17 13:39:41 +00:00
if (!shown_err) {
printf("error while reading: %s\n", fxp_error());
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
shown_err = true;
The xfer mechanism wasn't gracefully terminating when an error was encountered part way through transfer. In particular, this caused psftp to hang (waiting for FXP_READ replies which had already arrived) if you try `get' (without -r) on a remote directory. [originally from svn r5005]
2004-12-17 13:39:41 +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
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;
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
}
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 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
while (xfer_download_data(xfer, &vbuf, &len)) {
unsigned char *buf = (unsigned char *)vbuf;
wpos = 0;
while (wpos < len) {
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
wlen = write_to_file(file, buf + wpos, len - wpos);
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
if (wlen <= 0) {
printf("error while writing local file\n");
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;
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_set_error(xfer);
When we get an error writing to a local file, stop the download rather than pretending we just got -1 bytes. Not actually tested, but it looks pretty obvious. Bug reported by dking wang. [originally from svn r7459]
2007-04-10 21:46:44 +00:00
break;
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
}
wpos += wlen;
}
if (wpos < len) { /* we had an 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
toret = false;
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_set_error(xfer);
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
}
Obvious memory leak in new fast download management. Oops. [originally from svn r3471]
2003-09-29 15:39:36 +00:00
sfree(vbuf);
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
}
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) {
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;
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 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;
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
DirHandle *dh;
int 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
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
/*
* First, attempt to create the destination directory,
* unless it already exists.
*/
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(outfname);
pktin = sftp_wait_for_reply(req);
result = fxp_stat_recv(pktin, req, &attrs);
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 (!result ||
!(attrs.flags & SSH_FILEXFER_ATTR_PERMISSIONS) ||
!(attrs.permissions & 0040000)) {
Give fxp_mkdir_send an attrs parameter. It's not used anywhere, but this would make it one step easier to add a mode argument to PSFTP's mkdir command, if anyone needs it. Mostly the point is to get rid of the FIXME comment in fxp_mkdir_send itself.
2018-10-06 10:52:04 +00:00
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);
result = fxp_mkdir_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
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 (!result) {
printf("%s: create directory: %s\n",
outfname, 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
return 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
}
}
/*
* Now get the list of filenames in the local directory.
*/
nnames = namesize = 0;
ournames = NULL;
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
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
dh = open_directory(fname, &opendir_err);
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 (!dh) {
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
printf("%s: unable to open directory: %s\n", fname, opendir_err);
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 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
}
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 ((name = read_filename(dh)) != NULL) {
if (nnames >= namesize) {
namesize += 128;
ournames = sresize(ournames, namesize, char *);
}
ournames[nnames++] = name;
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
close_directory(dh);
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
/*
* 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
/*
* 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;
nextoutfname = dupcat(outfname, "/", ournames[i], 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
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]
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
* 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]);
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
nextoutfname = dupcat(outfname, "/", ournames[i], 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
retd = sftp_put_file(nextfname, nextoutfname, recurse, restart);
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
restart = false; /* after first partial file, do full */
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(nextoutfname);
sfree(nextfname);
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) {
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
for (i = 0; i < nnames; i++) {
sfree(ournames[i]);
}
sfree(ournames);
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 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
}
}
/*
* Done this recursion level. Free everything.
*/
for (i = 0; i < nnames; i++) {
sfree(ournames[i]);
}
sfree(ournames);
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;
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) {
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
printf("local: unable to open %s\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 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) {
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(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 {
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(outfname,
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) {
Patch from Tim Kosse to make PSFTP remember to close files on various error conditions. [originally from svn r8109]
2008-07-06 12:11:34 +00:00
close_rfile(file);
Everywhere we print an fxp_error(), try to make it clear what we were trying to do at the time. (A lot of these say just "canonify:". This isn't a nice thing to show to a user, but I don't believe canonify() will ever return failure due to a server error, so users shouldn't actually see it, and it means we have a chance of tracing it if reported.) [originally from svn r6636]
2006-04-13 21:18:09 +00:00
printf("%s: open for write: %s\n", outfname, 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
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) {
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
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_fstat_send(fh);
pktin = sftp_wait_for_reply(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
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
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) {
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("read size of %s: %s\n", outfname, 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;
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;
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 (!(attrs.flags & SSH_FILEXFER_ATTR_SIZE)) {
printf("read size of %s: size was not given\n", 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
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;
More upgrades to psftp: it now supports mv, chmod, reget and reput. [originally from svn r1203]
2001-08-26 11:35:11 +00:00
}
offset = attrs.size;
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
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
if (seek_file((WFile *)file, offset, FROM_START) != 0)
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
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)) {
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 buffer[4096];
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
int len, 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
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_upload_ready(xfer) && !err && !eof) {
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
len = read_from_file(file, buffer, sizeof(buffer));
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
if (len == -1) {
printf("error while reading local file\n");
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;
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
} else if (len == 0) {
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 = true;
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
} else {
xfer_upload_data(xfer, buffer, len);
}
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 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
Spotted by Tim Kosse: reput on an already complete file was hanging. Should be fixed now (we only wait for packets if we know there are some that haven't been replied to yet). [originally from svn r3618]
2003-12-03 23:25:48 +00:00
if (!xfer_done(xfer)) {
pktin = sftp_recv();
ret = xfer_upload_gotpkt(xfer, pktin);
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 <= 0) {
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
}
Spotted by Tim Kosse: reput on an already complete file was hanging. Should be fixed now (we only wait for packets if we know there are some that haven't been replied to yet). [originally from svn r3618]
2003-12-03 23:25:48 +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)) {
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
if (!err) {
printf("error while closing: %s", 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;
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] == '/')
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 NULL;
}
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) {
swcm = snew(SftpWildcardMatcher);
swcm->dirh = dirh;
swcm->names = NULL;
swcm->wildcard = dupstr(wildcard);
swcm->prefix = unwcdir;
} else {
printf("Unable to open %s: %s\n", cdir, fxp_error());
swcm = NULL;
sfree(unwcdir);
}
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) {
if (swcm->names && swcm->namepos >= swcm->names->nnames) {
fxp_free_names(swcm->names);
swcm->names = NULL;
}
if (!swcm->names) {
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_readdir_send(swcm->dirh);
pktin = sftp_wait_for_reply(req);
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
if (!swcm->names) {
if (fxp_error_type() != SSH_FX_EOF)
printf("%s: reading directory: %s\n", swcm->prefix,
fxp_error());
return NULL;
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
} else if (swcm->names->nnames == 0) {
/*
* 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
swcm->namepos = 0;
}
assert(swcm->names && swcm->namepos < swcm->names->nnames);
name = &swcm->names->names[swcm->namepos++];
if (!strcmp(name->filename, ".") || !strcmp(name->filename, ".."))
continue; /* expected bad filenames */
if (!vet_filename(name->filename)) {
printf("ignoring potentially dangerous server-"
"supplied filename '%s'\n", name->filename);
continue; /* unexpected bad filename */
}
if (!wc_match(swcm->wildcard, name->filename))
continue; /* doesn't match the wildcard */
/*
* We have a working filename. Return it.
*/
return dupprintf("%s%s%s", swcm->prefix,
"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
(!swcm->prefix[0] ||
swcm->prefix[strlen(swcm->prefix)-1]=='/' ?
"" : "/"),
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
name->filename);
}
}
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)
fxp_free_names(swcm->names);
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) {
SftpWildcardMatcher *swcm = sftp_begin_wildcard_matching(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
bool matched = 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
sfree(unwcfname);
if (!swcm)
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 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
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;
"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
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);
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
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;
"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(cname);
}
if (!matched) {
/* Politely warn the user that nothing matched. */
printf("%s: nothing matched\n", filename);
}
sftp_finish_wildcard_matching(swcm);
} else {
cname = canonify(unwcfname);
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 = func(ctx, 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
sfree(cname);
sfree(unwcfname);
}
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;
int nwords, wordssize;
int (*obey) (struct sftp_command *); /* returns <0 to quit */
};
int sftp_cmd_null(struct sftp_command *cmd)
{
return 1; /* success */
}
int sftp_cmd_unknown(struct sftp_command *cmd)
{
printf("psftp: unknown command \"%s\"\n", cmd->words[0]);
return 0; /* failure */
}
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) {
Localise "not connected to a host" messages. [originally from svn r5060]
2005-01-01 16:43:19 +00:00
not_connected();
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
return 0;
}
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)) {
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
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;
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
sftp_recvdata(&ch, 1);
}
do_sftp_cleanup();
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
/*
* 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;
struct fxp_name **ournames;
int nnames, namesize;
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
int 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
if (!backend) {
Localise "not connected to a host" messages. [originally from svn r5060]
2005-01-01 16:43:19 +00:00
not_connected();
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 0;
}
if (cmd->nwords < 2)
dir = ".";
else
dir = cmd->words[1];
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)) {
dir = unwcdir;
wildcard = NULL;
} else {
char *tmpdir;
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;
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);
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(dir, false);
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 = 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;
}
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);
printf("Listing directory %s\n", cdir);
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) {
printf("Unable to open %s: %s\n", dir, fxp_error());
Fixes spotted by Coverity. A lenof() being applied to a non-array, a couple of missing frees on an error path, and a case in pfd_receive() where we could have gone round a loop again after freeing the port forwarding structure it was working on.
2017-06-20 20:17:43 +00:00
sfree(cdir);
sfree(unwcdir);
Regard dir/ls on non-existent directory as an error. sftp_cmd_ls - return an error if attempting to open the directory fails.
2017-02-18 22:46:38 +00:00
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 {
nnames = namesize = 0;
ournames = NULL;
while (1) {
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_readdir_send(dirh);
pktin = sftp_wait_for_reply(req);
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
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;
}
if (nnames + names->nnames >= namesize) {
namesize += names->nnames + 128;
ournames = sresize(ournames, namesize, struct fxp_name *);
}
for (i = 0; i < names->nnames; i++)
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
if (!wildcard || wc_match(wildcard, names->names[i].filename))
ournames[nnames++] = fxp_dup_name(&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
fxp_free_names(names);
}
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
/*
* Now we have our filenames. Sort them by actual file
* name, and then output the longname parts.
*/
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
/*
* And print them.
*/
for (i = 0; i < nnames; i++) {
printf("%s\n", ournames[i]->longname);
fxp_free_name(ournames[i]);
}
sfree(ournames);
}
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) {
Localise "not connected to a host" messages. [originally from svn r5060]
2005-01-01 16:43:19 +00:00
not_connected();
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 0;
}
if (cmd->nwords < 2)
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 {
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
dir = canonify(cmd->words[1]);
}
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) {
printf("Directory %s: %s\n", dir, fxp_error());
sfree(dir);
return 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_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;
printf("Remote directory is now %s\n", pwd);
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) {
Localise "not connected to a host" messages. [originally from svn r5060]
2005-01-01 16:43:19 +00:00
not_connected();
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 0;
}
printf("Remote directory is %s\n", pwd);
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) {
Localise "not connected to a host" messages. [originally from svn r5060]
2005-01-01 16:43:19 +00:00
not_connected();
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 0;
}
i = 1;
while (i < cmd->nwords && cmd->words[i][0] == '-') {
if (!strcmp(cmd->words[i], "--")) {
/* finish processing options */
i++;
break;
} else if (!strcmp(cmd->words[i], "-r")) {
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
recurse = 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
} else {
Update online help for "-r" and "--" options to get/put commands. Use command name in error messages rather than hardcoded "get:"/"put:". [originally from svn r5002]
2004-12-17 12:15:17 +00:00
printf("%s: unrecognised option '%s'\n", cmd->words[0], cmd->words[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
return 0;
}
i++;
}
if (i >= cmd->nwords) {
Update online help for "-r" and "--" options to get/put commands. Use command name in error messages rather than hardcoded "get:"/"put:". [originally from svn r5002]
2004-12-17 12:15:17 +00:00
printf("%s: expects a filename\n", cmd->words[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
return 0;
}
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 {
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;
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
origfname = cmd->words[i++];
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
unwcfname = snewn(strlen(origfname)+1, char);
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
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;
}
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
} else {
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
origwfname = origfname;
swcm = NULL;
}
while (origwfname) {
fname = canonify(origwfname);
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
if (!multiple && i < cmd->nwords)
outfname = cmd->words[i++];
else
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
outfname = stripslashes(origwfname, 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
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 = sftp_get_file(fname, outfname, recurse, restart);
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
sfree(fname);
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) {
sfree(origwfname);
origwfname = sftp_wildcard_get_filename(swcm);
} else {
origwfname = NULL;
}
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
}
sfree(unwcfname);
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)
sftp_finish_wildcard_matching(swcm);
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 (!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) {
Localise "not connected to a host" messages. [originally from svn r5060]
2005-01-01 16:43:19 +00:00
not_connected();
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 0;
}
i = 1;
while (i < cmd->nwords && cmd->words[i][0] == '-') {
if (!strcmp(cmd->words[i], "--")) {
/* finish processing options */
i++;
break;
} else if (!strcmp(cmd->words[i], "-r")) {
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
recurse = 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
} else {
Update online help for "-r" and "--" options to get/put commands. Use command name in error messages rather than hardcoded "get:"/"put:". [originally from svn r5002]
2004-12-17 12:15:17 +00:00
printf("%s: unrecognised option '%s'\n", cmd->words[0], cmd->words[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
return 0;
}
i++;
}
if (i >= cmd->nwords) {
Update online help for "-r" and "--" options to get/put commands. Use command name in error messages rather than hardcoded "get:"/"put:". [originally from svn r5002]
2004-12-17 12:15:17 +00:00
printf("%s: expects a filename\n", cmd->words[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
return 0;
}
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 {
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
WildcardMatcher *wcm;
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
fname = cmd->words[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
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
if (multiple && test_wildcard(fname, false) == WCTYPE_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
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;
}
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
} else {
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
wfname = fname;
wcm = NULL;
}
while (wfname) {
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
if (!multiple && i < cmd->nwords)
origoutfname = cmd->words[i++];
else
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
origoutfname = stripslashes(wfname, true);
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
outfname = canonify(origoutfname);
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 = sftp_put_file(wfname, outfname, recurse, restart);
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
sfree(outfname);
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 (wcm) {
sfree(wfname);
wfname = wildcard_get_filename(wcm);
} else {
wfname = NULL;
}
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
}
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 (wcm)
finish_wildcard_matching(wcm);
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 (!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) {
Localise "not connected to a host" messages. [originally from svn r5060]
2005-01-01 16:43:19 +00:00
not_connected();
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;
}
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) {
printf("mkdir: expects a directory\n");
return 0;
}
"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++) {
dir = canonify(cmd->words[i]);
Give fxp_mkdir_send an attrs parameter. It's not used anywhere, but this would make it one step easier to add a mode argument to PSFTP's mkdir command, if anyone needs it. Mostly the point is to get rid of the FIXME comment in fxp_mkdir_send itself.
2018-10-06 10:52:04 +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);
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
if (!result) {
printf("mkdir %s: %s\n", dir, fxp_error());
ret = 0;
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
} else
printf("mkdir %s: OK\n", 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
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) {
"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("rmdir %s: %s\n", dir, 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
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) {
Localise "not connected to a host" messages. [originally from svn r5060]
2005-01-01 16:43:19 +00:00
not_connected();
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;
}
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) {
printf("rmdir: expects a directory\n");
return 0;
}
"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++)
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) {
"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("rm %s: %s\n", fname, 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
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) {
Localise "not connected to a host" messages. [originally from svn r5060]
2005-01-01 16:43:19 +00:00
not_connected();
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;
}
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) {
printf("rm: expects a filename\n");
return 0;
}
"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++)
ret &= wildcard_iterate(cmd->words[i], sftp_action_rm, NULL);
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 &&
(attrs.flags & SSH_FILEXFER_ATTR_PERMISSIONS) &&
(attrs.permissions & 0040000))
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 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
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;
"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) {
char *p;
char *newname;
p = srcfname + strlen(srcfname);
while (p > srcfname && p[-1] != '/') p--;
newname = dupcat(ctx->dstfname, "/", p, NULL);
newcanon = canonify(newname);
sfree(newname);
finalfname = newcanon;
} else {
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) {
printf("mv %s %s: %s\n", srcfname, finalfname, 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
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 {
printf("%s -> %s\n", srcfname, finalfname);
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;
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)
{
"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 actx, *ctx = &actx;
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) {
Localise "not connected to a host" messages. [originally from svn r5060]
2005-01-01 16:43:19 +00:00
not_connected();
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;
}
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) {
printf("mv: expects two filenames\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
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) {
printf("mv: multiple or wildcard arguments require the destination"
" to be a directory\n");
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);
More upgrades to psftp: it now supports mv, chmod, reget and reput. [originally from svn r1203]
2001-08-26 11:35:11 +00:00
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
/*
* Now iterate over the source arguments.
*/
ret = 1;
for (i = 1; i < cmd->nwords-1; i++)
ret &= wildcard_iterate(cmd->words[i], sftp_action_mv, ctx);
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)) {
printf("get attrs for %s: %s\n", fname,
result ? "file permissions not provided" : 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
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)
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; /* 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) {
printf("set attrs for %s: %s\n", fname, 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
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;
struct sftp_context_chmod actx, *ctx = &actx;
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) {
Localise "not connected to a host" messages. [originally from svn r5060]
2005-01-01 16:43:19 +00:00
not_connected();
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;
}
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) {
printf("chmod: expects a mode specifier and a filename\n");
return 0;
}
/*
* 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') {
if (mode[strspn(mode, "01234567")]) {
printf("chmod: numeric file modes should"
" contain digits 0-7 only\n");
return 0;
}
"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 = 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 {
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",
And just to prove that psftp.c really is now platform-independent ... here's a Unix port of PSFTP. Woo. (Oddly PSCP looks to be somewhat harder; there's more Windows code interleaved than there was in PSFTP.) [originally from svn r3419]
2003-08-24 13:22:17 +00:00
(int)strcspn(modebegin, ","), modebegin, *mode);
More upgrades to psftp: it now supports mv, chmod, reget and reput. [originally from svn r1203]
2001-08-26 11:35:11 +00:00
return 0;
}
mode++;
}
if (!*mode || *mode == ',') {
printf("chmod: file mode '%.*s' is incomplete\n",
And just to prove that psftp.c really is now platform-independent ... here's a Unix port of PSFTP. Woo. (Oddly PSCP looks to be somewhat harder; there's more Windows code interleaved than there was in PSFTP.) [originally from svn r3419]
2003-08-24 13:22:17 +00:00
(int)strcspn(modebegin, ","), modebegin);
More upgrades to psftp: it now supports mv, chmod, reget and reput. [originally from svn r1203]
2001-08-26 11:35:11 +00:00
return 0;
}
action = *mode++;
if (!*mode || *mode == ',') {
printf("chmod: file mode '%.*s' is incomplete\n",
And just to prove that psftp.c really is now platform-independent ... here's a Unix port of PSFTP. Woo. (Oddly PSCP looks to be somewhat harder; there's more Windows code interleaved than there was in PSFTP.) [originally from svn r3419]
2003-08-24 13:22:17 +00:00
(int)strcspn(modebegin, ","), modebegin);
More upgrades to psftp: it now supports mv, chmod, reget and reput. [originally from svn r1203]
2001-08-26 11:35:11 +00:00
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",
And just to prove that psftp.c really is now platform-independent ... here's a Unix port of PSFTP. Woo. (Oddly PSCP looks to be somewhat harder; there's more Windows code interleaved than there was in PSFTP.) [originally from svn r3419]
2003-08-24 13:22:17 +00:00
(int)strcspn(modebegin, ","), modebegin);
More upgrades to psftp: it now supports mv, chmod, reget and reput. [originally from svn r1203]
2001-08-26 11:35:11 +00:00
return 0;
}
perms |= 06000;
break;
default:
printf("chmod: file mode '%.*s' contains unrecognised"
" permission specifier '%c'\n",
And just to prove that psftp.c really is now platform-independent ... here's a Unix port of PSFTP. Woo. (Oddly PSCP looks to be somewhat harder; there's more Windows code interleaved than there was in PSFTP.) [originally from svn r3419]
2003-08-24 13:22:17 +00:00
(int)strcspn(modebegin, ","), modebegin, *mode);
More upgrades to psftp: it now supports mv, chmod, reget and reput. [originally from svn r1203]
2001-08-26 11:35:11 +00:00
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",
And just to prove that psftp.c really is now platform-independent ... here's a Unix port of PSFTP. Woo. (Oddly PSCP looks to be somewhat harder; there's more Windows code interleaved than there was in PSFTP.) [originally from svn r3419]
2003-08-24 13:22:17 +00:00
(int)strcspn(modebegin, ","), modebegin);
More upgrades to psftp: it now supports mv, chmod, reget and reput. [originally from svn r1203]
2001-08-26 11:35:11 +00:00
return 0;
}
perms &= subset;
switch (action) {
case '+':
"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 |= perms;
ctx->attrs_xor |= perms;
More upgrades to psftp: it now supports mv, chmod, reget and reput. [originally from svn r1203]
2001-08-26 11:35:11 +00:00
break;
case '-':
"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 |= perms;
ctx->attrs_xor &= ~perms;
More upgrades to psftp: it now supports mv, chmod, reget and reput. [originally from svn r1203]
2001-08-26 11:35:11 +00:00
break;
case '=':
"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 |= subset;
ctx->attrs_xor |= perms;
More upgrades to psftp: it now supports mv, chmod, reget and reput. [originally from svn r1203]
2001-08-26 11:35:11 +00:00
break;
}
if (*mode) mode++; /* eat comma */
}
}
"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++)
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) {
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
printf("psftp: already connected\n");
return 0;
}
if (cmd->nwords < 2) {
printf("open: expects a host name\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
if (cmd->nwords > 2) {
portnumber = atoi(cmd->words[2]);
if (portnumber == 0) {
printf("open: invalid port number\n");
return 0;
}
} else
portnumber = 0;
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 */
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 -1; /* this is fatal */
}
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) {
printf("lcd: expects a local directory name\n");
return 0;
}
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) {
printf("lcd: unable to change directory: %s\n", errmsg);
sfree(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
return 0;
}
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:
*
* - 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.
*
* - 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
{
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
"!", true, "run a local command",
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
"<command>\n"
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
/* FIXME: this example is crap for non-Windows. */
" Runs a local command. For example, \"!del myfile\".\n",
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
sftp_cmd_pling
},
{
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
"bye", true, "finish your SFTP session",
Add online help in PSFTP. [originally from svn r1261]
2001-09-09 16:29:51 +00:00
"\n"
" Terminates your SFTP session and quits the PSFTP program.\n",
sftp_cmd_quit
},
{
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
"cd", true, "change your remote working directory",
Document recent changes to PSFTP (and other documentation tweaks). [originally from svn r5058]
2005-01-01 16:16:13 +00:00
" [ <new working directory> ]\n"
Add online help in PSFTP. [originally from svn r1261]
2001-09-09 16:29:51 +00:00
" 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
},
{
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
"chmod", true, "change file permissions and modes",
Document recent changes to PSFTP (and other documentation tweaks). [originally from svn r5058]
2005-01-01 16:16:13 +00:00
" <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"
Add online help in PSFTP. [originally from svn r1261]
2001-09-09 16:29:51 +00:00
" 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
},
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
{
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
"close", true, "finish your SFTP session but do not quit PSFTP",
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
"\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
},
Add online help in PSFTP. [originally from svn r1261]
2001-09-09 16:29:51 +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
"del", true, "delete files on the remote server",
Document recent changes to PSFTP (and other documentation tweaks). [originally from svn r5058]
2005-01-01 16:16:13 +00:00
" <filename-or-wildcard> [ <filename-or-wildcard>... ]\n"
" Delete a file or files from the server.\n",
Add online help in PSFTP. [originally from svn r1261]
2001-09-09 16:29:51 +00:00
sftp_cmd_rm
},
{
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
"delete", false, "del", NULL, sftp_cmd_rm
Add online help in PSFTP. [originally from svn r1261]
2001-09-09 16:29:51 +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
"dir", true, "list remote files",
Update online help for "-r" and "--" options to get/put commands. Use command name in error messages rather than hardcoded "get:"/"put:". [originally from svn r5002]
2004-12-17 12:15:17 +00:00
" [ <directory-name> ]/[ <wildcard> ]\n"
Add online help in PSFTP. [originally from svn r1261]
2001-09-09 16:29:51 +00:00
" List the contents of a specified directory on the server.\n"
" If <directory-name> is not given, the current working directory\n"
Update online help for "-r" and "--" options to get/put commands. Use command name in error messages rather than hardcoded "get:"/"put:". [originally from svn r5002]
2004-12-17 12:15:17 +00:00
" is assumed.\n"
" If <wildcard> is given, it is treated as a set of files to\n"
" list; otherwise, all files are listed.\n",
Add online help in PSFTP. [originally from svn r1261]
2001-09-09 16:29:51 +00:00
sftp_cmd_ls
},
{
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
"exit", true, "bye", NULL, sftp_cmd_quit
Add online help in PSFTP. [originally from svn r1261]
2001-09-09 16:29:51 +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
"get", true, "download a file from the server to your local machine",
Update online help for "-r" and "--" options to get/put commands. Use command name in error messages rather than hardcoded "get:"/"put:". [originally from svn r5002]
2004-12-17 12:15:17 +00:00
" [ -r ] [ -- ] <filename> [ <local-filename> ]\n"
Add online help in PSFTP. [originally from svn r1261]
2001-09-09 16:29:51 +00:00
" 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"
Update online help for "-r" and "--" options to get/put commands. Use command name in error messages rather than hardcoded "get:"/"put:". [originally from svn r5002]
2004-12-17 12:15:17 +00:00
" argument <local-filename>.\n"
" If -r specified, recursively fetch a directory.\n",
Add online help in PSFTP. [originally from svn r1261]
2001-09-09 16:29:51 +00:00
sftp_cmd_get
},
{
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
"help", true, "give help",
Add online help in PSFTP. [originally from svn r1261]
2001-09-09 16:29:51 +00:00
" [ <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
},
{
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
"lcd", true, "change local working directory",
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
" <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
},
{
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
"lpwd", true, "print local working directory",
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
"\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
},
{
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
"ls", true, "dir", NULL,
Add online help in PSFTP. [originally from svn r1261]
2001-09-09 16:29:51 +00:00
sftp_cmd_ls
},
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
{
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
"mget", true, "download multiple files at once",
Update online help for "-r" and "--" options to get/put commands. Use command name in error messages rather than hardcoded "get:"/"put:". [originally from svn r5002]
2004-12-17 12:15:17 +00:00
" [ -r ] [ -- ] <filename-or-wildcard> [ <filename-or-wildcard>... ]\n"
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
" 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"
Update online help for "-r" and "--" options to get/put commands. Use command name in error messages rather than hardcoded "get:"/"put:". [originally from svn r5002]
2004-12-17 12:15:17 +00:00
" such as \"*.c\" to specify lots of files at once.\n"
" If -r specified, recursively fetch files and directories.\n",
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
sftp_cmd_mget
},
Add online help in PSFTP. [originally from svn r1261]
2001-09-09 16:29:51 +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
"mkdir", true, "create directories on the remote server",
Document recent changes to PSFTP (and other documentation tweaks). [originally from svn r5058]
2005-01-01 16:16:13 +00:00
" <directory-name> [ <directory-name>... ]\n"
" Creates directories with the given names on the server.\n",
Add online help in PSFTP. [originally from svn r1261]
2001-09-09 16:29:51 +00:00
sftp_cmd_mkdir
},
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
{
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
"mput", true, "upload multiple files at once",
Missed options off mput help [originally from svn r5010]
2004-12-18 10:46:21 +00:00
" [ -r ] [ -- ] <filename-or-wildcard> [ <filename-or-wildcard>... ]\n"
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
" 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"
Update online help for "-r" and "--" options to get/put commands. Use command name in error messages rather than hardcoded "get:"/"put:". [originally from svn r5002]
2004-12-17 12:15:17 +00:00
" such as \"*.c\" to specify lots of files at once.\n"
" If -r specified, recursively store files and directories.\n",
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
sftp_cmd_mput
},
Add online help in PSFTP. [originally from svn r1261]
2001-09-09 16:29:51 +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
"mv", true, "move or rename file(s) on the remote server",
Document recent changes to PSFTP (and other documentation tweaks). [originally from svn r5058]
2005-01-01 16:16:13 +00:00
" <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",
Add online help in PSFTP. [originally from svn r1261]
2001-09-09 16:29:51 +00:00
sftp_cmd_mv
},
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
{
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
"open", true, "connect to a host",
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
" [<user>@]<hostname> [<port>]\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
" Establishes an SFTP connection to a given host. Only usable\n"
Document recent changes to PSFTP (and other documentation tweaks). [originally from svn r5058]
2005-01-01 16:16:13 +00:00
" when you are not already connected to a server.\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
sftp_cmd_open
},
The alphabetical ordering in the psftp command list was broken. D'oh! [originally from svn r1508]
2001-12-19 18:49:32 +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
"put", true, "upload a file from your local machine to the server",
Update online help for "-r" and "--" options to get/put commands. Use command name in error messages rather than hardcoded "get:"/"put:". [originally from svn r5002]
2004-12-17 12:15:17 +00:00
" [ -r ] [ -- ] <filename> [ <remote-filename> ]\n"
The alphabetical ordering in the psftp command list was broken. D'oh! [originally from svn r1508]
2001-12-19 18:49:32 +00:00
" 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"
Update online help for "-r" and "--" options to get/put commands. Use command name in error messages rather than hardcoded "get:"/"put:". [originally from svn r5002]
2004-12-17 12:15:17 +00:00
" argument <remote-filename>.\n"
" If -r specified, recursively store a directory.\n",
The alphabetical ordering in the psftp command list was broken. D'oh! [originally from svn r1508]
2001-12-19 18:49:32 +00:00
sftp_cmd_put
},
Add the `pwd' command in PSFTP. [originally from svn r1262]
2001-09-09 16:31:26 +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
"pwd", true, "print your remote working directory",
Add the `pwd' command in PSFTP. [originally from svn r1262]
2001-09-09 16:31:26 +00:00
"\n"
" Print the current remote working directory for your SFTP session.\n",
sftp_cmd_pwd
},
Add online help in PSFTP. [originally from svn r1261]
2001-09-09 16:29:51 +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
"quit", true, "bye", NULL,
Add online help in PSFTP. [originally from svn r1261]
2001-09-09 16:29:51 +00:00
sftp_cmd_quit
},
{
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
"reget", true, "continue downloading files",
Update online help for "-r" and "--" options to get/put commands. Use command name in error messages rather than hardcoded "get:"/"put:". [originally from svn r5002]
2004-12-17 12:15:17 +00:00
" [ -r ] [ -- ] <filename> [ <local-filename> ]\n"
Add online help in PSFTP. [originally from svn r1261]
2001-09-09 16:29:51 +00:00
" Works exactly like the \"get\" command, but the local file\n"
" must already exist. The download will begin at the end of the\n"
Update online help for "-r" and "--" options to get/put commands. Use command name in error messages rather than hardcoded "get:"/"put:". [originally from svn r5002]
2004-12-17 12:15:17 +00:00
" file. This is for resuming a download that was interrupted.\n"
" If -r specified, resume interrupted \"get -r\".\n",
Add online help in PSFTP. [originally from svn r1261]
2001-09-09 16:29:51 +00:00
sftp_cmd_reget
},
{
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
"ren", true, "mv", NULL,
Add online help in PSFTP. [originally from svn r1261]
2001-09-09 16:29:51 +00:00
sftp_cmd_mv
},
{
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
"rename", false, "mv", NULL,
Add online help in PSFTP. [originally from svn r1261]
2001-09-09 16:29:51 +00:00
sftp_cmd_mv
},
{
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
"reput", true, "continue uploading files",
Update online help for "-r" and "--" options to get/put commands. Use command name in error messages rather than hardcoded "get:"/"put:". [originally from svn r5002]
2004-12-17 12:15:17 +00:00
" [ -r ] [ -- ] <filename> [ <remote-filename> ]\n"
Add online help in PSFTP. [originally from svn r1261]
2001-09-09 16:29:51 +00:00
" Works exactly like the \"put\" command, but the remote file\n"
" must already exist. The upload will begin at the end of the\n"
Update online help for "-r" and "--" options to get/put commands. Use command name in error messages rather than hardcoded "get:"/"put:". [originally from svn r5002]
2004-12-17 12:15:17 +00:00
" file. This is for resuming an upload that was interrupted.\n"
" If -r specified, resume interrupted \"put -r\".\n",
Add online help in PSFTP. [originally from svn r1261]
2001-09-09 16:29:51 +00:00
sftp_cmd_reput
},
{
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
"rm", true, "del", NULL,
Add online help in PSFTP. [originally from svn r1261]
2001-09-09 16:29:51 +00:00
sftp_cmd_rm
},
{
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
"rmdir", true, "remove directories on the remote server",
Document recent changes to PSFTP (and other documentation tweaks). [originally from svn r5058]
2005-01-01 16:16:13 +00:00
" <directory-name> [ <directory-name>... ]\n"
Add online help in PSFTP. [originally from svn r1261]
2001-09-09 16:29:51 +00:00
" Removes the directory with the given name on the server.\n"
Document recent changes to PSFTP (and other documentation tweaks). [originally from svn r5058]
2005-01-01 16:16:13 +00:00
" The directory will not be removed unless it is empty.\n"
" Wildcards may be used to specify multiple directories.\n",
Add online help in PSFTP. [originally from svn r1261]
2001-09-09 16:29:51 +00:00
sftp_cmd_rmdir
}
};
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;
j = sizeof(sftp_lookup) / sizeof(*sftp_lookup);
while (j - i > 1) {
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];
}
}
return NULL;
}
static int sftp_cmd_help(struct sftp_command *cmd)
{
int i;
if (cmd->nwords == 1) {
/*
* Give short help on each command.
*/
int maxlen;
maxlen = 0;
for (i = 0; i < sizeof(sftp_lookup) / sizeof(*sftp_lookup); i++) {
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
int len;
if (!sftp_lookup[i].listed)
continue;
len = strlen(sftp_lookup[i].name);
Add online help in PSFTP. [originally from svn r1261]
2001-09-09 16:29:51 +00:00
if (maxlen < len)
maxlen = len;
}
for (i = 0; i < sizeof(sftp_lookup) / sizeof(*sftp_lookup); i++) {
const struct sftp_cmd_lookup *lookup;
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 (!sftp_lookup[i].listed)
continue;
Add online help in PSFTP. [originally from svn r1261]
2001-09-09 16:29:51 +00:00
lookup = &sftp_lookup[i];
printf("%-*s", maxlen+2, lookup->name);
if (lookup->longhelp == NULL)
lookup = lookup_command(lookup->shorthelp);
printf("%s\n", lookup->shorthelp);
}
} else {
/*
* 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);
}
}
}
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) {
if (modeflags & 1)
printf("psftp> ");
line = fgetline(fp);
} 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) {
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);
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
return cmd; /* eof */
}
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) {
printf("%s\n", 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
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'))
p++;
if (*p == '!') {
/*
* Special case: the ! command. This is always parsed as
* exactly two words: one containing the !, and the second
* containing everything else on the line.
*/
cmd->nwords = cmd->wordssize = 2;
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->words = sresize(cmd->words, cmd->wordssize, char *);
Joe Yates's memory leak patches. [originally from svn r3650]
2003-12-19 12:44:46 +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 == '#') {
/*
* 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 {
/*
* 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"<
*/
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
while (1) {
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
/* 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;
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
/* mark start of word */
q = r = p; /* q sits at start, r writes word */
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
quoting = false;
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) {
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';
if (cmd->nwords >= cmd->wordssize) {
cmd->wordssize = cmd->nwords + 16;
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->words = sresize(cmd->words, cmd->wordssize, char *);
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
}
Joe Yates's memory leak patches. [originally from svn r3650]
2003-12-19 12:44:46 +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)
cmd->obey = sftp_cmd_null;
else {
Add online help in PSFTP. [originally from svn r1261]
2001-09-09 16:29:51 +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
/*
* Do protocol initialisation.
*/
if (!fxp_init()) {
fprintf(stderr,
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
"Fatal: unable to initialise SFTP: %s\n", fxp_error());
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 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) {
fprintf(stderr,
"Warning: failed to resolve home directory: %s\n",
fxp_error());
homedir = dupstr(".");
} else {
printf("Remote working directory is %s\n", homedir);
}
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;
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
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);
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
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) {
sfree(pwd);
pwd = NULL;
}
if (homedir) {
sfree(homedir);
homedir = NULL;
}
}
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) {
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
struct sftp_command *cmd;
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
cmd = sftp_getcmd(NULL, 0, 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 (!cmd)
break;
Joe Yates's memory leak patches. [originally from svn r3650]
2003-12-19 12:44:46 +00:00
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)
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
break;
Add online help in PSFTP. [originally from svn r1261]
2001-09-09 16:29:51 +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
} else {
fp = fopen(batchfile, "r");
if (!fp) {
Add online help in PSFTP. [originally from svn r1261]
2001-09-09 16:29:51 +00:00
printf("Fatal: unable to open %s\n", batchfile);
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 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
}
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 = 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) {
Add online help in PSFTP. [originally from svn r1261]
2001-09-09 16:29:51 +00:00
struct sftp_command *cmd;
cmd = sftp_getcmd(fp, mode, modeflags);
if (!cmd)
break;
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
ret = cmd->obey(cmd);
if (ret < 0)
Add online help in PSFTP. [originally from svn r1261]
2001-09-09 16:29:51 +00:00
break;
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 (ret == 0) {
Add online help in PSFTP. [originally from svn r1261]
2001-09-09 16:29:51 +00:00
if (!(modeflags & 2))
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
break;
Add online help in PSFTP. [originally from svn r1261]
2001-09-09 16:29:51 +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
}
Add online help in PSFTP. [originally from svn r1261]
2001-09-09 16:29:51 +00:00
fclose(fp);
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
/*
* 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
Asynchronous agent requests on Windows. Actually, I've kept the ability to do synchronous ones as well, because PSCP and PSFTP don't really need async ones and it would have been a serious pain to implement them. Also, Pageant itself when run as a client of its primary instance doesn't benefit noticeably from async agent requests. [originally from svn r3154]
2003-04-28 13:59:32 +00:00
/*
* In psftp, all agent requests should be synchronous, so this is a
* never-called stub.
*/
void agent_schedule_callback(void (*callback)(void *, void *, int),
void *callback_ctx, void *data, int len)
{
assert(!"We shouldn't be here");
}
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;
static int psftp_output(Seat *seat, bool is_stderr, const void *data, int 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
/*
* stderr data is just spouted to local stderr and otherwise
* ignored.
*/
if (is_stderr) {
Remove all the "assert(len>0)" which forbade zero-length writes across the from_backend() interface, after having made all implementations safe against being called with len==0 and possibly-NULL/undefined "data". (This includes making misc.c:bufchain_add() more robust in this area.) Assertion was originally added 2002-03-01; e.g., see plink.c:1.53 [r1571]. I believe this now shouldn't break anything. This should hopefully make `ppk-empty-comment' finally GO AWAY. (Tested with Unix PuTTY.) [originally from svn r3500] [r1571 == fdbd6978016e9fd87db7b3bfc33ff0da8bd3eea9]
2003-10-12 13:16:39 +00:00
if (len > 0)
Workarounds for compiling with -D_FORTIFY_SOURCE=2 (as Ubuntu does), which doesn't like you to ignore the return value from read()/write()/etc (and apparently can't be shut up with a cast to void). [originally from svn r8614]
2009-08-07 00:19:04 +00:00
if (fwrite(data, 1, len, stderr) < len)
/* oh well */;
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
}
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
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_recvdata(char *buf, int 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
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
int got = bufchain_fetch_consume_up_to(&received_data, buf, len);
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
}
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_senddata(char *buf, int 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
}
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
int sftp_sendbuffer(void)
{
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");
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;
Make 'LogContext' a typedef visible throughout the code. Same principle again - the more of these structures have globally visible tags (even if the structure contents are still opaque in most places), the fewer of them I can mistake for each other.
2018-09-11 14:17:16 +00:00
LogContext *logctx;
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) {
host = userhost;
} else {
*host++ = '\0';
if (user) {
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
printf("psftp: multiple usernames specified; using \"%s\"\n",
user);
psftp now works as part of the PuTTY suite [originally from svn r940]
2001-02-24 16:08:56 +00:00
} else
user = userhost;
}
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".
*/
if (!loaded_session) {
/* Try to load settings for `host' into a temporary config */
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 *conf2 = conf_new();
conf_set_str(conf2, CONF_host, "");
do_defaults(host, conf2);
if (conf_get_str(conf2, CONF_host)[0] != '\0') {
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
/* Settings present and include hostname */
/* Re-load data into the real config. */
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
do_defaults(host, 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
} else {
/* Session doesn't exist or mention a hostname. */
/* Use `host' as a bare hostname. */
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_host, host);
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
}
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 {
/* Patch in hostname `host' to session details. */
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_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? */
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
*/
{
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
char *hostbuf = dupstr(conf_get_str(conf, CONF_host));
char *host = hostbuf;
char *p, *q;
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
/*
* Trim leading whitespace.
*/
host += strspn(host, " \t");
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
/*
* 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;
Fix for `hostname-whitespace'; thanks to Justin Bradford. [originally from svn r2080]
2002-10-16 11:35:13 +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
/*
* 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') {
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_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)
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_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
{
char *key;
while ((key = conf_get_str_nthstrkey(conf, CONF_portfwd, 0)) != NULL)
conf_del_str_str(conf, CONF_portfwd, key);
}
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.
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
*
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
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,
"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
Refactor the LogContext type. LogContext is now the owner of the logevent() function that back ends and so forth are constantly calling. Previously, logevent was owned by the Frontend, which would store the message into its list for the GUI Event Log dialog (or print it to standard error, or whatever) and then pass it _back_ to LogContext to write to the currently open log file. Now it's the other way round: LogContext gets the message from the back end first, writes it to its log file if it feels so inclined, and communicates it back to the front end. This means that lots of parts of the back end system no longer need to have a pointer to a full-on Frontend; the only thing they needed it for was logging, so now they just have a LogContext (which many of them had to have anyway, e.g. for logging SSH packets or session traffic). LogContext itself also doesn't get a full Frontend pointer any more: it now talks back to the front end via a little vtable of its own called LogPolicy, which contains the method that passes Event Log entries through, the old askappend() function that decides whether to truncate a pre-existing log file, and an emergency function for printing an especially prominent message if the log file can't be created. One minor nice effect of this is that console and GUI apps can implement that last function subtly differently, so that Unix console apps can write it with a plain \n instead of the \r\n (harmless but inelegant) that the old centralised implementation generated. One other consequence of this is that the LogContext has to be provided to backend_init() so that it's available to backends from the instant of creation, rather than being provided via a separate API call a couple of function calls later, because backends have typically started doing things that need logging (like making network connections) before the call to backend_provide_logctx. Fortunately, there's no case in the whole code base where we don't already have logctx by the time we make a backend (so I don't actually remember why I ever delayed providing one). So that shortens the backend API by one function, which is always nice. While I'm tidying up, I've also moved the printf-style logeventf() and the handy logevent_and_free() into logging.c, instead of having copies of them scattered around other places. This has also let me remove some stub functions from a couple of outlying applications like Pageant. Finally, I've removed the pointless "_tag" at the end of LogContext's official struct name.
2018-10-10 18:26:18 +00:00
logctx = log_init(default_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
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
platform_psftp_pre_conn_setup();
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
err = backend_init(&ssh_backend, psftp_seat, &backend, 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) {
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
fprintf(stderr, "ssh_init: %s\n", err);
psftp now works as part of the PuTTY suite [originally from svn r940]
2001-02-24 16:08:56 +00:00
return 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
while (!backend_sendok(backend)) {
if (backend_exitcode(backend) >= 0)
Patch from Tim Kosse: check back->exitcode() in both loops on ssh_sftp_loop_iteration(), not just one. Fixes exiting on a negative response to the host key confirmation prompt on Windows (because winsftp.c doesn't have the equivalent of uxsftp.c's no_fds_ok); on Unix it worked already but gave a suboptimal error message, which is fixed too by this patch. [originally from svn r8110]
2008-07-06 12:24:56 +00:00
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
if (ssh_sftp_loop_iteration() < 0) {
fprintf(stderr, "ssh_init: error during SSH connection setup\n");
return 1;
}
}
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)
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)
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
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;
char *batchfile = NULL;
Remove FLAG_STDERR completely. Originally, it controlled whether ssh.c should send terminal messages (such as login and password prompts) to terminal.c or to stderr. But we've had the from_backend() abstraction for ages now, which even has an existing flag to indicate that the data is stderr rather than stdout data; applications which set FLAG_STDERR are precisely those that link against uxcons or wincons, so from_backend will do the expected thing anyway with data sent to it with that flag set. So there's no reason ssh.c can't just unconditionally pass everything through that, and remove the special case. FLAG_STDERR was also used by winproxy and uxproxy to decide whether to capture standard error from a local proxy command, or whether to let the proxy command send its diagnostics directly to the usual standard error. On reflection, I think it's better to unconditionally capture the proxy's stderr, for three reasons. Firstly, it means proxy diagnostics are prefixed with 'proxy:' so that you can tell them apart from any other stderr spew (which used to be particularly confusing if both the main application and the proxy command were instances of Plink); secondly, proxy diagnostics are now reliably copied to packet log files along with all the other Event Log entries, even by command-line tools; and thirdly, this means the option to suppress proxy command diagnostics after the main session starts will actually _work_ in the command-line tools, which it previously couldn't. A more minor structure change is that copying of Event Log messages to stderr in verbose mode is now done by wincons/uxcons, instead of centrally in logging.c (since logging.c can now no longer check FLAG_STDERR to decide whether to do it). The total amount of code to do this is considerably smaller than the defensive-sounding comment in logevent.c explaining why I did it the other way instead :-)
2018-09-21 15:15:49 +00:00
flags = FLAG_INTERACTIVE
And just to prove that psftp.c really is now platform-independent ... here's a Unix port of PSFTP. Woo. (Oddly PSCP looks to be somewhat harder; there's more Windows code interleaved than there was in PSFTP.) [originally from svn r3419]
2003-08-24 13:22:17 +00:00
#ifdef FLAG_SYNCAGENT
| FLAG_SYNCAGENT
#endif
;
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
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
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);
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
loaded_session = false;
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++) {
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
int 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
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]);
continue;
}
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
ret = cmdline_process_param(argv[i], i+1<argc?argv[i+1]:NULL, 1, 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
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'. */
if (flags & FLAG_VERBOSE)
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
verbose = 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
} else if (strcmp(argv[i], "-h") == 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], "-?") == 0 ||
strcmp(argv[i], "--help") == 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
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;
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
} else if (strcmp(argv[i], "-V") == 0 ||
strcmp(argv[i], "--version") == 0) {
Add -V for version information to plink, pscp, and psftp. [originally from svn r4092]
2004-04-17 20:25:09 +00:00
version();
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
} else if (strcmp(argv[i], "-batch") == 0) {
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
console_batch_mode = 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
} else if (strcmp(argv[i], "-b") == 0 && i + 1 < argc) {
mode = 1;
batchfile = argv[++i];
Fix trivial problems with PSFTP batch mode [originally from svn r1483]
2001-12-14 10:06:09 +00:00
} else if (strcmp(argv[i], "-bc") == 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
modeflags = modeflags | 1;
Fix trivial problems with PSFTP batch mode [originally from svn r1483]
2001-12-14 10:06:09 +00:00
} else if (strcmp(argv[i], "-be") == 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
modeflags = modeflags | 2;
} else if (strcmp(argv[i], "--") == 0) {
i++;
break;
} else {
Fixes for more robust handling of command-line parse errors. [originally from svn r2236]
2002-11-20 20:09:02 +00:00
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
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') {
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) {
Joe Yates's memory leak patches. [originally from svn r3650]
2003-12-19 12:44:46 +00:00
int ret;
ret = psftp_connect(userhost, user, portnumber);
sfree(userhost);
if (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
return 1;
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
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 {
printf("psftp: no hostname specified; use \"open host.name\""
Joe Yates's memory leak patches. [originally from svn r3650]
2003-12-19 12:44:46 +00:00
" 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)) {
psftp now works as part of the PuTTY suite [originally from svn r940]
2001-02-24 16:08:56 +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;
psftp now works as part of the PuTTY suite [originally from svn r940]
2001-02-24 16:08:56 +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();
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
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