From owner-freebsd-arch@freebsd.org Sun Jun 24 10:39:56 2018 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id EDDCE10234DE for ; Sun, 24 Jun 2018 10:39:55 +0000 (UTC) (envelope-from lists@eitanadler.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 7DABE8399D for ; Sun, 24 Jun 2018 10:39:55 +0000 (UTC) (envelope-from lists@eitanadler.com) Received: by mailman.ysv.freebsd.org (Postfix) id 3733D10234DD; Sun, 24 Jun 2018 10:39:55 +0000 (UTC) Delivered-To: arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 244E610234DC for ; Sun, 24 Jun 2018 10:39:55 +0000 (UTC) (envelope-from lists@eitanadler.com) Received: from mail-yb0-x22c.google.com (mail-yb0-x22c.google.com [IPv6:2607:f8b0:4002:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id ACBD18399C for ; Sun, 24 Jun 2018 10:39:54 +0000 (UTC) (envelope-from lists@eitanadler.com) Received: by mail-yb0-x22c.google.com with SMTP id s14-v6so4113382ybp.13 for ; Sun, 24 Jun 2018 03:39:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eitanadler.com; s=0xdeadbeef; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-transfer-encoding; bh=F7X2sd4eRk7B4alRI3V0ZDUQ47Vi2m20Oje8rNwTOJc=; b=q5azbO2H3LktqPCVCl94ZG8At7xdfuJiGU6efpNhfATk3l+xqhhw55Brde561fVafx qVMNvtfXUctoSGc6TBJ+5dZ/UpSzi+2waGpp5Yo3/wEnYhsooHqhbU6V33Ug5ZkMa15Y 8kTzAEuZ29EEiuTyh4ueT17ovIodixQEh5nGU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:content-transfer-encoding; bh=F7X2sd4eRk7B4alRI3V0ZDUQ47Vi2m20Oje8rNwTOJc=; b=PW1y/p85xEVXFqwmopM4wseNmfPSL9GQ6K1/3nAFK4Fzy6S13TxmwHKGZ2llyneVew oDBkEic6moZAE2m2Nji3L1i/EHBAEpFD/Uw8IBZaJWVxmnaJ0EWdQaTJh/lDjHJnuQMP 8r/8fZoZoCFzRL73bvHutsQzNRezaVI1zdxwZ+gBSn0LU3KP0qMm46FXR5lXDUtPJYjI WdN6RXjEPkDCe0uVoYgSunxWJ+IpR4Oth1WKt4V1laLGghgnQ3NZgiTqPUSvM0aZNbfL F1+2IksDRhbsNa/8unOGHG4E0rhKMgvRPupB1i/rai5VkN2HNXjYm+4iwMVz73WtIyJf cGaA== X-Gm-Message-State: APt69E2W3q493yd6+ObBI+H6YPily2HXgTDpZ1C9fNgVVkvdXj37NMQP 1+pXBldPgefy4P8LKHVo8MNz8LeTf4Y0PjsyCfkTrA== X-Google-Smtp-Source: ADUXVKI+ugPbsfQnkK6SgjM1pVxVejmvW8rLqOzy8IG4dFpUpOf1hutRubjoVLNBoZ/HSeE4zN0GM+q1o3x3NojiF6o= X-Received: by 2002:a25:786:: with SMTP id 128-v6mr4331723ybh.338.1529836793843; Sun, 24 Jun 2018 03:39:53 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a25:ef50:0:0:0:0:0 with HTTP; Sun, 24 Jun 2018 03:39:23 -0700 (PDT) In-Reply-To: References: From: Eitan Adler Date: Sun, 24 Jun 2018 03:39:23 -0700 Message-ID: Subject: Re: What to do about rcmdsh(3) ? To: "freebsd-arch@freebsd.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jun 2018 10:39:56 -0000 On 24 June 2018 at 03:32, Eitan Adler wrote: > Now that the rcmds are removed from base, it opens a question about > what to do with rcmdsh(3). > This is documented as > rcmdsh =E2=80=93 return a stream to a remote command without superus= er > And is implemented as a rather simple wrapper of getaddrinfo and exec. > > This isn't something I'd imagine we'd add to libc now-a-days and is > currently broken by default (due to defaulting to _PATH_RSH) > > I'm not sure there is much value in keeping this function around. I > did a rather naive search for uses of this function in ports and > couldn't find any. I'm preparing a more comprehensive patch for an > exp-run. > > Does anyone have a reason to keep in libc? Any objection to removing > it? If no, is there anything special I need to do beyond just removing > the implementation and references? Since I'm sending emails at 3:30am anyways, I'll point that generally applies to rcmd(3) and related too. I don't really understand the use-case for these functions on modern system= s. --=20 Eitan Adler