From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933019AbcFBWl5 (ORCPT ); Thu, 2 Jun 2016 18:41:57 -0400 Received: from mail-wm0-f46.google.com ([74.125.82.46]:36453 "EHLO mail-wm0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932279AbcFBWlz (ORCPT ); Thu, 2 Jun 2016 18:41:55 -0400 User-Agent: K-9 Mail for Android In-Reply-To: <20160602041934.GA13820@milliways.localdomain> References: <87lh2pj0gi.fsf@gmail.com> <1A095838-A4DA-4215-8AB7-6ACC92802F0D@gmail.com> <9d6adc59-3893-18f9-c003-c54a1db9e3cc@gmail.com> <20160602041934.GA13820@milliways.localdomain> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 Subject: Re: script relative shebang From: Boris Date: Thu, 02 Jun 2016 23:41:44 +0100 To: Ken Moffat CC: "Austin S. Hemmelgarn" , Nicolai Stange , linux-kernel@vger.kernel.org, Vladimir Sapronov Message-ID: <3EFB0946-2224-46B0-B109-12E1556260FD@gmail.com> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org I still think it is a good thing to do. I will try to implement it on github and may be some day someone influential will help me with that :) On 2 June 2016 05:19:34 BST, Ken Moffat wrote: >On Thu, Jun 02, 2016 at 01:04:46AM +0100, Boris Rybalkin wrote: >> Sorry for insisting, but I would like to explore potential solutions >> for fixing the root problem (missing relative shebang), >> I know there are ways to workaround that, but I would like to make >> sure the proper fix is not possible. >> I understood that it is too late to introduce additional keywords >> after #! as existing systems expect fs path there, OK. >> But what about changing #! itself, is it possible to introduce >another >> special sequence like #? to denote a relative mode: >> >> #?python/bin/python >> >If you are able to get that accepted, it will only work on linux >systems running such recent kernels. For your own systems, you can >of course do whatever you wish. But for public availability you >will then need to wait several years until your target linux users >can be expected to have moved to a suitable kernel (presumably the >*next* long-term stable kernel after the change is accepted : I >guess that version is perhaps the best part of a year away even if >your change got accepted into 4.8, and then you need your users' >distros to move to it). > >To me, that doesn't seem worth the trouble (to you) of coding it, >getting it reviewed and eventually accepted, and then fixing up >whatever problems arise after it gets into linux-next [ problems >will always appear, even if the new code turns out not to be the >cause ]. > >And first, you have to persuade somebody influential that this is a >good thing to do, particularly when people have suggested >alternative approaches. I don't count, but at the moment I've not >seen any good reasons why the kernel should be changed to support >this. > >But it's your time, and your itch to scratch. > >ĸen -- Sent from my Android device with K-9 Mail. Please excuse my brevity.